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This document describes the use of the commands which maintain 
the environment established for design, development, evaluation and 
integration of the NOS/VE system, using NOS/VE as the basis for that 
environment. 

Initially, of course, the user may need to convert NOS libraries, 
binaries, and files to 180 format. For a brief discussion of this, 
please see Appendix C. Migration will present different problems 
for different people. In an effort to make NOS/VE more usable, a 
utility has been provided as an "ear" for user complaints. Any bug 
(or feature) that a user encounters which is difficult to 
understand, makes life harder, or prevents one from accomplishing 
work should be "sent to integration". 

The Integration Source Maintenance Commands enable access to the 
source code, object code, etc. in "logical" terms rather than in 
terms that require knowledge of the physical structure of the 
information. For example, if a developer wishes to compile a module 
at a certain build level of the system, he would need to specify the 
name assigned to that build level rather than the file(s) or catalog 
on which that level of the system reside. Creation, modification, 
compilation, formatting, and transmittal of decks are all handled by 
these procedures. 

Some background is supplied first in the following sections, with 
command usage subsequent. 
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From the point of view of a developer of NOS/VE code the source 
exists in three levels. 

The main level is maintained by NOS/VE Integration and resides 
in the "development base" (INTVE). 

In most cases a number of individual developers are working on 
the same feature, so there is a "feature catalog" shared by 
those developers which sits between their working catalog and 
the main integration source catalog. 

At the local level, each developer has their own "working 
catalog" which is a subset of the feature and/or system 
source. 

Thus each feature catalog contains a unique subset of the main data 
base and each working catalog contains a unique subset of the 
corresponding feature subset. 

When a feature is being handled by a single developer, the "feature" 
level and "local" level may effectively be one and the same. 

The information (source library, object libraries, etc.) in the 
feature and working subset catalogs will parallel the structure used 
in the main integration catalog; i.e. the same subcatalog 
hierarchy, file names, etc. will be used. 

The relationship of these catalogs is illustrated below. 
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2.1 MAIN INTEGRATION CATALOG (INTVE) 

This catalog holds the main level of the software development 
data base and all of the commands and tools needed to maintain 
and manipulate it. It contains the following : 

a library of commands used to access and manipulate 
the source (.INTVE.Command Library) 
a subcatalog for the operating system (OS) 
a subcatalog for each product (SCU,ASSEMBLER,FTN,etc.) 
(Note that in this context the following are considered to 
be products : 

"system tests" 
test tools 

system level documentation (e.g. AO/R, release 
bulletins, etc.) 


The following diagram illustrates the overall structure 
of this catalog. 
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Remember that each product subcatalog contains a structure 
matching that of OS. OS is essentially one of several 
products. Each working catalog contains a structure 
matching that of the OS, also. 
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2.2 OPERATING SYSTEM SUBCATALOG (OS) 


This subcatalog contains all the data necessary to 
build and test a NOS/VE system. In particular it contains 
the SCU source library for all versions of NOS/VE, and a 
subcatalog for each version (build level) of the system. 
These subcatalogs contain the object libraries, NOS 
libraries, and whatever else may be required for the 
corresponding level. See Appendix A on Representation of 
multiple build levels. 


2.3 SYSTEM SOURCE LIBRARY 


The SCU library for the operating system contains the 
following : 

the source code for the operating system and system 

supplied utilities for both virtual state and real 

state (OSS$SOURCE, OSS$REAL_STATE_SOURCE) 

the source code the system's external interfaces 

(OSS$PROGRAM_INTERFACE) 

the source code for NOS/VE feature tests 
miscellaneous "files" needed to build NOS/VE such as 
linker subcommands, selection criteria, etc. 

The system source library will actually be kept in two 
files : 


SOURCE LIBRARY contains the main library 
LATEST CHANGES contains additions and changes to the 
main library that have not yet been merged into it. 
In other words it is the recipient of all code 
transmittals from development. 

Although there are physically two 
source libraries, they should be 
thought of as one "logical" library. 

The reason for having two separate files is twofold. 
The primary reason is to remove the need for a developer 
to have to rewrite 100 plus Mbyte files (in the case of 
OS). The second reason ties into the algorithm used in 
parallel source library maintenance. See "User 

Documentation for NOS/VE Integration" for more details. 
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Integration will periodically merge the "latest 
changes" with the main library. This will happen 
approximately once per day. See "User Documentation for 
NOS/VE Integration" parallel source library maintenance 
chapter for more details. 


2.3.1 GROUPS ON THE SOURCE LIBRARY 


Critical to the structure of the Source Library, and to 
the efficiency of the source maintenance procedures, is 
the association of SCU "group names" with each deck on the 
library. These groups may be used to manipulate "blocks" 
or "groups" of decks, such as all decks in a job template 
or system core library, fairly easily. (See Appendix B 
for specific information on the naming conventions for 
these groups.) 

Integration will set up the major groups on the Source 
Library (NOSVEPL et al) when the library is converted. 
After that, group attributes will generally be established 
at deck creation time. 


2.3.2 USE OF "FEATURES" AND "MODIFICATIONS" 


Every modification to the source generated by a developer 
will be associated with an SCU "feature". Features are 
used to identify what PSR, DAP, or increment the 
modifications associated with it are addressing. 
Modifications are used to identify code authored by an 
individual that is part of (or all of) a "feature". A 
modification may affect more than one deck. 

Modification names will have the following form : 

iii nnnnn 

where iii are the initials of the author of the 
modification and nnnnn is a one to five digit sequence 
number for modifications authored by iii. In the case 
where two developers have the same initials, the fourth 
character (normally an underscore) can be changed to 
resolve the conflict. The generation of these 
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modification names is handled and tracked automatically by 
the Integration procedures. 


2.3.3 USE OF INTERLOCKS 


SCU deck interlocks are used to avoid the problems 
caused by more than one person making a change to the same 
deck at the same time. 

The commands described later use the following policies 
when moving information between the levels of the data 
base. 

Whenever a deck is extracted for the purpose of 
modifying it, the extraction is done using the SCU 
command EXTRACT_SOURCE_LIBRARY with interlocks 
enabled. This is true both when extracting from the 
main system library to a feature library, and from a 
feature library to a working library. This is 
accomplished via the Extract Source procedure. When 
a deck is extracted from a library with interlocks 
it contains all modifications made to that deck up 
to that point. 

Whenever a modification is transmitted the affected 
decks must be recombined with the library from which 
they were extracted using the SCU command 
COMBINE_LIBRARY with interlock checking enabled. 
This is accomplished via the Transmit To Integration 
command. 
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3.0 COMMANDS TO USE THE NOS/VE MAINTENANCE ENVIRONMENT 


A library of commands (mostly SCL procedures) provides 
access to the source. These commands use standard 
facilities of NOS/VE and its product set. In addition 
tools provided by the Software Tools and Technology group 
will be utilized. 

There is a command library for use by designers, 
developers, evaluators and integrators to access and 
maintain the source, and to access any "non-standard" 
tools. 

These commands are maintained on the NOS/VE source 
library. Refer to Appendix G for copies of the actual 
procedure definitions. 

To access these commands the user must add the command 
library to his/her command list. This is accomplished 
simply by entering : 

Set Command List add=.INTVE.Command Library 

To facilitate this, the set command list could be added 
to the user's prolog. As a result, the commands appear to 
the user to be system commands. 

Some of the commands described below will create a new 
cycle of a file. When this operation would take place on 
a temporary file that file will be overwritten (this is 
because NOS/VE does not support cycles for temporary 
files). When this operation takes place on a permanent 
file, cycle 1 of the file is first written (as a scratch 
file) and when this has successfully completed, the $NEXT 
cycle will be written and cycle 1 purged. In this way the 
integrity of the SHIGH cycle of the library should be 
maintained. To facilitate this, users are asked to keep 
cycle 1 of their Source Library file empty. For such 
files in integration catalogs, the previously highest 
cycle will be deleted. 

The deleting of old cycles of source libraries from 
feature and working catalogs will take place automatically 
via an archive during PE BACKUP. The expiration date of 
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old cycles of files will be set by the procedures. 


3.1 ENVIRONMENT COMMANDS 


The commands described in this section are used to 
specify the "environment" in which work will be done. 

Particular parts of the environment can be specified on 
most of the commands, but the commands are much more 
convenient to use if the environment parameters are 
established prior to work starting (via the 
Set Working Environment command). 

Normally the SET_WORKING_ENVIRONMENT command is called 
from within the user's prolog thus establishing the 
environment at each login. 

Other commands that care about an environment parameter 
will default that parameter to the value specified on the 
SET_WORKING_ENVIRONMENT command. If that command hasn't 
been called, the default used is that specified in the 
description of the corresponding parameter of the 
SET_WORKING_ENVIRONMENT command. 

All procedures (except those named) 
described in this document will work 
either within or outside of the 
working environment "utility". The 
exceptions to this are : 
EXTRACT_SOURCE, RE_EXTRACT_SOURCE, 

CHANGE_MODIFICATION_HEADER, 
CLEAR_INTERLOCK_REQUEST, 

TRANSMIT_TO_INTEGRATION, and 
TRANSIT TO FEATURE CATALOG. 


3.1.1 DISPLAY WORKING ENVIRONMENT (DISWE) 


This command displays the values of the working 
environment parameters that have been established by 
Set Working Environment. 
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display working environment 

display options : list of name 
output : file 
status : status 


display option | display options | do : specifies which 
working environment parameters are to be displayed. 
The legal values for this parameters are the names of 
the working environment parameters, and their 
abbreviations, as specified for the 

set working environment command, plus the keyword ALL 
meaning display all working environment parameters. 

Omission causes ALL to be used. 

output I o : specifies the file to receive the display. 

Omission causes $OUTPUT to be used. 

status : see NOS/VE error handling. 


3.1.2 ENTER WORKING ENVIRONMENT (ENTWE) 


This command should be used when a number of changes 
need to be made to the working source library. It calls 
SCU such that the base parameter is the source library in 
the working catalog and the result parameter is a new 
cycle of that source library. 

This command provides a more efficient way of doing 
work than "popping in and out" of SCU to do editing, deck 
expansion, etc. For example, a user may enter the SCU 
utility, make some changes to a deck, compile it (without 
having to exit SCU and thus write a new cycle of the 
working library) , fix whatever problems may show up in 
the compile, compile again, etc. Only when finished with 
that particular work session does the user need to leave 
SCU. 

When the working environment is entered, the highest 
cycle of source library in the working environment is used 
as the base and cycle 1 of source library in the working 
environment is specified as the result file. Checkpoints 
of updates to the source library can be made via SCU's 
WRITE LIBRARY subcommand with no parameters when in the 
working environment. This will overwrite cycle 1 of the 
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source library in the working environment working 
catalog. Cycle 1 of the source library is set to the 
highest cycle when exiting working environment via the 
EXIT_WORKING_ENVIRONMENT command. 

The ENTER_WORKING_ENVIRONMENT command will support a 
Prolog file called "WORKING_ENVIRONMENT_PROLOG" in the 
working catalog. This file will be invoked prior to a 
user's commands being accepted. 

To inhibit writing the next cycle of source library so 
that no changes will be made, type in "END FALSE". Typing 
in "END" or "END TRUE" has the same effect as "END 
FALSE". In all of these cases, cycle 1 of source library 
is purged so the changes are lost. The only way to save 
the changes is by typing "EXIWE" or 
"EXIT_WORKING_ENVIRONMENT". 

Not all commands can be used from within the working 
environment. See section 3.1 for commands that work 
properly inside the working environment. 


enter working environment 

author : string = $job(user) 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build level : name = object 
target_operating_system : key 
status : status 


author | a : specifies the caller's name, to be recorded 
as the author of any decks or modifications created 
by this user. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 
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build_level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

target operating system | tos : specifies which 170 system 
to generate a 180 system for. The only valid values 
are NOS and NOS/BE. 

Omission causes NOS to be used. 

status : see NOS/VE error handling. 


3.1.3 EXIT WORKING 

ENVIRONMENT 

(EXIWE) 




This 

command is 

used to 

exit from 

the 

working 

environment created 

by a 

preceding 

call 

to the 


ENTER_WORKING_ENVIRONMENT command. 

If changes have been made since the working environment 
was "entered" the new cycle of the working source library 
is written. If no changes were made, the new cycle is 
discarded. 


exit working environment 
status : status 


status : see NOS/VE error handling. 



User Documentation for Development on NOS/VE 
Working Draft - Revision 7 

3.0 COMMANDS TO USE THE NOS/VE MAINTENANCE ENVIRONMENT 
3.1.4 SET WORKING ENVIRONMENT (SETWE) 


3-6 

08/25/91 


3.1.4 SET WORKING ENVIRONMENT (SETWE) 


This command is used to create or change command 
language variables that specify the level of system or 
product to be used as a basis for work and the "feature" 
and "working" catalogs being used. The parameters 
specified in this command can also be specified on ALL of 
the other commands described in this document. The 
defaults for these parameters are the same in each 
command. However, once values for them have been 
established by the Set Working Environment command, they 
need not be specified again unless the user wishes to 
access a different catalog or build level. 

Omission of a parameter will cause a default value to 
be picked if the corresponding variable is undefined, or 
if defined the corresponding value will be left 
unchanged. 

All command language variables set by this command will 
have a scope of JOB and their names will begin with the 
characters WEVS. The variable names used are specified 
with the corresponding parameter. 

This command is normally called from a user's prolog. 


set working environment 

author : string = $job(user) 

development base : file = .intve 

product name : name = os 

build level : name 

tools library build level : name 

feature catalog : file or key none = none 

feature build level : name = object 

working catalog : file or key none = none 

working build level : name = object 

target_operating_system : key 

status : status 


author | a : specifies the caller's name, to be recorded 
as the author of any decks or modifications created 
by this user. 


The corresponding variable name is WEV$AUTHOR. 
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Omission causes the user name of the caller to be 
used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the name of the product to 
be worked on. This is the name of the operating 
system or product subcatalog in the main integration 
catalog. 

The corresponding variable name is WEV$PRODUCT_NAME. 
The default is OS. 

build level | bl : specifies the name of the system or 
product build level to be used as the basis for 
work. 

The corresponding variable name is WEV$BUILD LEVEL. 

The default is the latest product build level. 

tools library_build level | tbl : specifies the build 
level of the tools command library to be added to the 
user's command list. If certain tools (compiler, 
linker, etc.) are unique for the build level of a 
product, a tools command library will exist for the 
build level of that product. 

The corresponding variable name is 

WEV$TOOLS_LIBRARY_BUILD_LEVEL. 

The default is the value of the BUILD LEVEL 
parameter. 

feature catalog | fc : specifies the catalog in which the 
files and subcatalogs corresponding to a feature are 
located. 

The corresponding variable name is 

WEV$FEATURE CATALOG. 


The default is to have no feature catalog (a value of 
'NONE'). 



User Documentation for Development on NOS/VE 
Working Draft - Revision 7 

3.0 COMMANDS TO USE THE NOS/VE MAINTENANCE ENVIRONMENT 
3.1.4 SET WORKING ENVIRONMENT (SETWE) 


3-8 

08/25/91 


feature build level | fbl : specifies the name of the 
feature build level to be used. This is analogous to 
the system or product build level but designates the 
version of the feature to be used. The initial 
implementation of these commands will support only 
one "feature build level". 

The corresponding variable name is 

WEV$FEATURE_BUILD_LEVEL. 

The default is OBJECT. 

working catalog | wc : specifies the catalog in which the 
files and subcatalogs corresponding to a developers 
current work are located. 

The corresponding variable name is 

WEV$WORKING_CATALOG. 

The default is to have no working catalog (a value of 
'NONE'). 

working build level | wbl : specifies the name of the 
working build level to be used. This is analogous to 
the feature build level but designates the "working" 
version to be used. The initial implementation of 
these commands will support only one "working build 
level". 

The corresponding variable name is 

WEV$WORKING_BUILD_LEVEL. 

The default is OBJECT. 

target operating system | tos : specifies which 170 system 
to generate a 180 system for. The only valid values 
are NOS and NOS/BE. 

Omission causes NOS to be used. 


status : see NOS/VE error handling. 
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3.2 COMMANDS FOR CODE DEVELOPMENT AND INTEGRATION 


The commands described in the following subsections are 
intended to be used by developers (and evaluators in their 
role as developers of tests) and integrators to access 
system oriented source. Parameters to these commands are 
the same as corresponding parameters in standard system 
utilities such as SCU and CYBIL. For example the Cybil 
list options parameter can also be used in the call to the 
Compile Source command. 


3.2.1 ASSIGN MODIFICATION(S) (ASSM) 


This command can be used inside the 
Working Environment. 

This command creates one or more unique modifications 
in the working source library. Any time the user wishes 
to create or modify a deck, a modification name must be 
supplied to the appropriate command. This modification 
must have been created by Assign Modification or must 
contain all information required by Assign modification. 

The names for the modifications are created from the 
"modification name seed" assigned to a user upon joining 
the project, and sequence number maintained in the user's 
prolog. This command will update the sequence number in 
the prolog, thus keeping track of modification names 
already used. 

The user must initiate this tracking scheme by entering 
the following two create variable commands in his/her 
prolog : 

create_variable WEV$MODIFICATION_INDEX kind : integer .. 
scope= job value= 1 (or whatever number desired to start) 

create variable wev$modification initials kind : string .. 
scope= job value= 'xyz ' (xyz is user's initials) 

The feature name specified is added to WEF$FEATURE LIST 
file in the user's working catalog. This file is a 
selection criteria file used by compile source and 
get source when expanding decks. There is no mechanism 
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for deleting features from WEF$FEATURE LIST except by 
editing it. 

The new version of the source library is written as the 
next cycle of the file. 


assign modification 
feature : name 
count : integer 

modification_description : string 
output : file 

author : string = $job(user) 
working_catalog : file or key none = none 
status : status 


feature | f : specifies the feature with which the 
modifications are to be associated. 

Required parameter. 

count I c : specifies the number of modifications to be 
assigned. 

Omission causes 1 to be used. 

modification description | md : specifies a brief 
description of the modifications. 

Required parameter. 

output I o : specifies the file to which are written the 
names of the modifications that have been created. 

Omission causes $OUTPUT to be used. 

author | a : specifies the creator of the contents of the 
modifications. 

working catalog | wc : specifies the working catalog to be 
used. 


status : see NOS/VE error handling. 
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3.2.2 ASSIGN AND RETURN MODIFICATION (ASSARM) 


This procedure calls assign modification and returns that 
modification in a stri to the modification parameter. 

assign and return modification 

feature, f : name = $required 
modification description, .. 
md : string = $required 
output, o : file = $local.$output 
author, a : string = $job(user) 
working catalog, wc : file = os 
modification, m : var of string = $optional 
status : var of status = $optional 

feature | f : specifies the feature with which the 
modifications are to be associated. 

Required parameter. 

modification description | md : specifies a brief 

description of the modifications. 

Required parameter. 

output I o : specifies the file to which are written the 
names of the modifications that have been created. 

Omission causes $OUTPUT to be used. 

author | a : specifies the creator of the contents of the 
modifications. 

working catalog | wc : specifies the working catalog to be 
used. 

modification | m : This is the string which is returned 
with the new modification name. 


status : See NOS/VE error handling. 
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3.2.3 BUILD EXEC (BUIE) 


The purpose of this procedure is to serve as a 
"watchdog" over the batch jobs produced by 
MAKE BUILD JOBS. This procedure will display each job's 
current status and allow the user to manipulate and 
resubmit the jobs. 

build_exec 

products, p : list of name 

display_job_logs, dj1 : key all, errors, e, none 

edit_jobs, ej : key all, errors, e, none 

resubmit_jobs, rj : key all, errors, e, none 

veto, V : boolean 

output, o : file 

build level, bl : name 

status : var of status 

products I p : This a list of product names for which 
MAKBJ has been run. The procedure assumes that the 
catalog structure matches the MAKBJ default, with 
each product's information in $USER.<build 
level>.<product name>.BJC. 

Default if omitted : the product setting from the 
working environment variable wev$product name. 

(Note : the keyword ALL will select all data on all 
products in the build job catalog.) 

display_job_logs | dj1 : This parameter causes the log 

file, $USER.<build level>.<product 

name>.BJC.JOB LOGS.<job> to be copied to <output>. 

Default if omitted : none. 

edit jobs | ej : This parameter will allow the user to 
edit the job file, $USER.<build level>.<product 
name>.BJC.<j ob>. 

Default if omitted : none. 

resumit jobs | rj : This selects whether to resumit a job 
or not. 


Default if omitted : no resubmit. 
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veto I V : This parameter causes a job-by-job interactive 
inquiry on each of the three operations selectable 
above. 

Default if omitted : false. 

output I This is the file that recieves all of the status 
information. 

build level | bl : specifies the system or product build 
level to be used. 

status : see NOS/VE error handling. 


3.2.4 CHANGE MODIFICATION HEADERS (CHAMH) 


The purpose of this procedure is to change information 
in modification headers on the product source library of 
modifications at state 1. Feature, author and the 
modification description are the only values that can be 
changed. The modification headers will not be updated 
immediately but at the next routine update of the product 
source library. 

NOTE : This procedure can only be executed from the 
master machine. 

change modification headers 

modification : list of name 
new feature : name 
new_author : string = $job(user) 
new description : string 
development base : file = .intve 
product name : name = os 
status : status 

modification | m : specifies the modifications to be 
changed. 

new feature | nf : specifies the feature to be assigned to 
the specified modifications. 

Omission results in no change. 


new author | na : specifies author to be assigned to the 
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specified modifications. 

Omission results in no change. 

new description | nd : specifies modification description 
to be assigned to the specified modifications. 

Omission results in no change. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

status : see NOS/VE error handling. 


3.2.5 CLEAR INTERLOCK REQUEST (CLEIR) 


The purpose of this procedure is to clear the interlock 
on decks the caller has interlocked. If the interlocked 
deck is on latest changes, it can be cleared immediately. 
If not, it is cleared at the next regular update of the 
product source library. If need arises to have someone 
else's interlock cleared, contact integration. 

NOTE : If the deck does not exist on latest changes, 
this request must be run on the master machine. 

clear interlock request 
deck : list of name 
development base : file = .intve 
product name : name = os 
status : status 

deck I d : specifies the deck whose interlock is to be 
cleared. 

development base | db : specifies the catalog in which all 
products and build levels reside. 


Default if omitted : .INTVE 
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product name | pn : specifies the system or product to 
use. 

status : see NOS/VE error handling. 


3.2.6 COMPILE SOURCE (COMS) 


This command can be used inside the 

Working Environment. 

This command compiles/assembles one or more decks. 

The defaults have been chosen for convenience of 
developers who will typically be dealing with a small 
number of modules at a time. 

Libraries are included in the list to be searched in 
the following order : 

Working library (if a working catalog is in effect) 
Feature library (if a feature catalog is in effect) 
Alternate bases (if alternate_bases are specified) 
Latest changes (if include_latest_changes is 
specified) 

OS or product source library 

Alternate product libraries (if alternate products 
are specified) 

At least one of the deck and selection criteria 
parameters must be provided. If both are given the deck 
parameter is processed first. If either processor or 
object_library (or both) is not specified, defaults are 
taken from the first deck in the compile list. 

Decks to be compiled are specified only by the DECK 
parameter and by the INCLUDE_DECK and INCLUDE_GROUP 
directives of the user selection criteria file (specified 
by the SELECTION CRITERIA parameter). Modifications to be 
applied against the selected decks are selected by the 
BUILD LEVEL and FEATURE parameters and by directives in 
the user selection criteria file. The 

INCLUDE LATEST CHANGES parameter indicates whether or not 
the LATEST CHANGES file in the product catalog is to be 
included as an alternate base. 
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The selection of decks and modifications is passed on 
to the SCU EXPAND DECK command (by this PROC) by parameter 
values on the command call and by the selection criteria 
file which this PROC always builds - whether or not the 
SELECTION CRITERIA parameter is specified on the PROC 
call. As a result of the call to SCU by this PROC, the 
following operations are performed : 

1. The various source libraries specified are merged. 
That is, certain directories such as the deck 
directories and the modification directories from 
the various libraries are merged. A deck which 
appears on more than one library is selected from 
the first library on which it is located. However, 
modification headers which may appear on more than 
one library are selected from the last library 
encountered. 

2. All modifications resulting from the merge are 

flagged as "included"; all decks, "excluded". 

3. All modifications in state 0 or 1 are excluded. 

This step is performed because there may be mods in 

these states which may be of no interest to the 
caller (they may actually be "bad"). This does mean 
that the current mods you are generating and testing 
will be excluded since they are in state 0, however, 
your mods will be added later either by the feature 
or selection criteria parameter or by your 

wef$feature list file. 

4. The directories are "rolled back" to the specified 
build level - that is, all new mods included in 
builds after the specified build are excluded. The 
directories should now be in the same configuration 
they were in when the build of the specified level 
was generated. This step is skipped if the value of 
the BUILD_LEVEL parameter is NONE. 

5. Modifications associated with the features specified 
by the FEATURE parameter are now "included". If the 
FEATURE parameter is not specified, the features 
selected will be those in the WEF$FEATURE LIST file 
of the working catalog. If this file does not exist 
or is empty and no value is specified for the 
FEATURE parameter, then no additional modifications 
will be included by this step. If the FEATURE 
parameter is given the keyword value of ALL, then 
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step 3 is essentially undone - that is, all 
modifications with state 0 or 1 are included. If 
the FEATURE parameter is given the keyword value of 
NONE, this step will result in no changes - that is, 
no modification introduced after the specified build 
level will be included. 

6. Decks specified by the DECK parameter are now 
included. Note that these are the only decks which 
have been selected for compilation. 

7. The SCU selection criteria file specified by the 
SELECTION CRITERIA parameter is now processed. The 
directives in this file may - intentially or 
inadvertantly - undo some of what has been done 
before. 

8. Unless both the PROCESSOR and OBJECT_LIBRARY 
parameters are specified on the call to 
COMPILE_SOURCE, the PROC will include some 
directives here to determine those values for the 
deck(s) under consideration. 

Specifying both the PROCESSOR and OBJECT_LIBRARY 
parameters causes all decks to be expanded and then 
compiled together. This is quicker than having the 
procedure determine processor and object library for each 
deck if there are a lot of them. 

When the procedure is run a sub catalog called 
compilation catalog is created in the working_catalog. As 
the modules are processed the object_text (Igo file) is 
written to a file in this catalog. The file name is the 
same as the destination object library which will be 
written to the maintenance sub catalog. Upon successful 
generation of the object_library, the object_text file is 
deleted. If there are no other files in the 
compilation_catalog sub_catalog, it is deleted also. 

When the procedure is run to compile something on the 
170 side, any existing working catalog copies of 170 
libraries are replaced to the 170 (if CLEANUP 170= BOTH or 
START) along with the text to compile. A partner job is 
executed on the 170 to compile the text. The NOS partner 
job generates the following : a compilation listing file, 
a status file and a dayfile of the 170 job. When 
compilation completes, the object text generated is 
replaced onto the specified object library. The three 
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special files mentioned above are then retrieved to the 
180 and massaged as follows : 

1. The 170 job dayfile is placed on $LOCAL.DAYFILE 170, 

2. If SAVE_LISTINGS<>NONE the listing file has its page 
headers altered to match the NOS/VE SIS. 

3. The status file is interpreted to report the result 
of the compilation. 

When all compilations have completed, the 170 object 
libraries are retrieved (if CLEANUP 170= BOTH or END) back 
to your working catalog. 


compile source 

deck : list of name 
selection criteria : file 
feature : list of name 
compile : file 
processor : string 
object library : list of name 
list : file 

list options : list of name 
listing library : name 
save listings : list of save options 
alternate product : list of list of name 
alternate base : list of file 
target_operating_system : key 

cleanup_170 : key START END BOTH NONE = BOTH 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build_level : name = object 
status : status 


deck I decks | d : specifies the decks to be compiled. 

selection criteria | sc : specifies the file containing 
SOU selection criteria commands that alone or in 
conjunction with the decks parameter select the decks 
to be compiled. 


Omission causes $NULL to be used. 
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NOTE : The selection criteria file cannot be an 
interactive file because there is no way to end 
it and allow SCU to continue processing 
selection criteria file directives which the 
procedure has to append. The selection criteria 
file should not contain an "END" command. 

feature | f : specifies what features are to be included 
when compiling specified decks. The keywords ALL or 
NONE are also allowable values. 

Omission causes file WEF$FEATURE LIST in the 
user's working catalog to be used if it exists. This 
file is maintained by the ASSIGN_MODIFICATION 
procedure. 

compile | c : specifies the name of the compile file to be 
generated. It is not disturbed when procedure 

completes. 


Omission causes a unique name to be used and the file 
is detached when procedure completes. 

processor | p : specifies the compiler or assembler to be 
used to process each deck. Processor options may be 
selected by giving this parameter as a string (e.g. 
'CYBIL DA=NONE OPT=HIGH RC=NONE' - which is the value 
used for closed shop and release system compiles). 

NOTE : If specifying the processor field and the 
processor is CYBIL, it is absolutely necessary 
to also specify DA=NONE (no debug tables). 
Modules with debug tables do not work when 
linked into the system. 

Omission causes each deck to be processed 
according to its "processor" attribute. 
Obviously the procedure will be more efficient 
if a processor is specified, as it will not 
have to process each deck individually. 

object_library | object_libraries | ol : specifies the 
object libraries in the working catalog into which 
the compiled/assembled modules will be placed. If an 
object library already exists the newly compiled 
modules are combined with it to form a new version of 
the library which effectively overwrites the 
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original. If NONE is specified, no object library or 
object file will be written. 

Omission causes the object libraries to be selected 
according to each deck's "destination group" 

attributes. 

list I 1 : specifies the file to which the 

compilation/assembly listings are to be written. 

Omission causes $LIST to be used. (Warning - in a 
batch job $LIST is connected to OUTPUT. If a 
listing is not desired in a batch job, $NULL 
should be specified for list.) 

list option I list options | lo : specifies the listing 

options to be used on each call to a 

compiler/assembler. See the documentation for each 

"processor" for valid options. 

Omission causes (S,R) to be used, i.e. a listing of 
the source and a cross reference (excluding 
unreferenced identifiers). This default is not 
currently valid for the 180 Assembler. If the 
user wants the processor default to take 
effect, DEFAULT should be specified in the call 
to the procedure. If the processor is CP or PP 
COMPASS, no list options are specified on 
processor call if the defaults (s,r) are 
specified. 

listing library | 11 : specifies the name of the 

listing library. 

save listings | si : specifies whether listings generated 
by compiler are to be saved on an SCU library in the 
working environment. Options are ALL, GOOD, BAD and 
NONE. GOOD and BAD refer to the absence or presence 
of compilation errors. 

Omission causes NONE to be used. 

alternate_product | alternate_products | ap : specifies 
other product catalogs in which to find 
source_libraries to be used as alternate_bases in the 
expansion of the code. This parameter accepts either 
single names or pairs or names as values. If an 
entry is a single value, it specifies an alternate 
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product name. If a pair of values is specified, the 
second element specifies the build level for the 
alternate product. If the second value is NONE or 
only a single value specified, a build level of NONE, 
which is all active lines at state 2 or higher is 
assumed. 

Omission causes no alternate_products to be 

accessed. 

alternate_base | alternate_bases | ab : specifies other 
files that may be required to properly expand the 
desired decks. 

Omission causes NONE to be used. 

cleanup 170 | c7 : This parameter is only used when 
compiling 170 language decks (COMPASS, SYMPL, CYBIL 
CC, CCL PROCS, etc.). It is used to control the 
replacement and retrieval of the 170 object libraries 
from the 180 to allow performance improvements. It 
is not recommended that this parameter be used unless 
the user is familiar with the implications it has for 
the procedures LINK 170 and GENDF as well as 
COMPILE_SOURCE. The valid values are : 

START : replace files, do NOT retrieve or purge 
them. 

END : do NOT replace files, retrieve and purge when 
done. 

BOTH : replace files, retrieve and purge when 
done. 

NONE : do NOT replace, retrieve, or purge files. 

Omission causes BOTH to be used. 

target operating system | tos : specifies which 170 system 
to generate a 180 system for. The only valid values 
are NOS and NOS/BE. 

Omission causes NOS to be used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 


product name | pn : specifies the system or product to be 
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used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.2.7 CREATE SOURCE (CRES) 


This command creates the new decks in the working 
source library. Once this is accomplished the text of the 
deck may be added via EDIT_LIBRARY or EDIT_SOURCE, or 
(indirectly) by any other editor. 

The new version of an affected source library is 
written as the next cycle of the corresponding file. 


create_source 

deck : list of name 

modification : name 

source group : name 

destination group : list of name 

group : list of name 

processor : string 

author : string = $job(user) 

deck description : string 

expand : boolean 

same as : name 

development base : file = .intve 
product name : name = os 

feature catalog : file or key none = none 
working catalog : file or key none = none 
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status : status 


deck I decks | d : specifies the decks to be created. 

modification | m : specifies the modification under which 
the decks are to be introduced. This modification 
must exist in the working library at state 0. 

source group | sg : specifies the group of decks to which 
the new decks are to be assigned, such as 
OSS$SOURCE. (See the section on "use of groups" 
above.) 

Required parameter. 

destination group | destination_groups | dg : specifies 
the file(s) in which the "processed" (compiled, 
assembled, etc.) form of the modules is to be 
placed. (See Appendix B) If this is not applicable 
(in the case of a common deck) NONE should be 
specified. 

Required parameter. 

group I groups | g : specifies the "arbitrary" groups to 
which the decks are to be assigned. (See Appendix B) 

Omission causes no "arbitrary" groups to be 

assigned. 

processor | p : specifies the processor for the decks. 
The processor is also added as a group unless it is 
the keyword NONE. 

Omission causes CYBIL to be used. 

author | a : specifies the creator of the contents of the 
decks. 

deck description | dd : specifies a brief description of 
the decks. If no description is desired, specify the 
string NONE. 

Required parameter. 

expand | e : specifies whether the decks are to be 
"directly expandable" i.e. written directly to a 
compile file (expand= true) or expandable only by 
being the object of a SOU *copy or *copyc text 
embedded directive (expand= false). (i.e. a common 
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deck) 

Omission causes a default to be chosen according to 
the syntax of the deck name (each deck will 
have its own default). If the fourth character 
of the deck name is "$" and the third character 
is not "M", the default is FALSE; otherwise the 
default is TRUE. 

same_as | sa : specifies that SCU deck attributes not 
specified with parameters above are to be taken from 
the named deck. 

Omission causes the normal SCU defaults to be used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

feature_catalog i fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.8 CREATE TESTNAMES LISTS (CREATE TESTNAMES LIST 


CREATE_TESTNAME_LISTS CREATE_TESTNAME_LIST CRETL) 

This procedure creates the data files needed to drive the 
automated testing utility. These files contain the names 
of the tests to be executed; broken down into various 
subsets and categories. New testname lists must be 
generated whenever tests are added or removed from the 
system. Canned directives exist on a deck called 
TDI$TESTNAMES product name or can be supplied by the 
TESTNAMES_DATA_FILE. ~ 

create_testnames_lists 

testname data file, tdf : file or key none 
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alternate_bases, alternate_base, ab : list of file or 
key none 

development base, db : file 

product name, pn : name 

feature catalog, fc : file or key none 

working catalog, wc : file or key none 

build level : name 

working build level, wbl : name 

mystery maintainer of future, mysmf : boolean 

help, h : file 

status : var of status 

testnames data file | tdf : This is a file of alternate 
directives for determining test subsets. 

alternate_bases | ab : This is a list of source libraries 
to be searched in addition to the standard 

(integration, f_c, w_c) set 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name I pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

working build_level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.2.9 DISPLAY BUILD INFORMATION (DISBI) 


This procedure displays the build information of 
specified build or cycle level. The information displayed 
is about various components of a NOS/VE build, such as NOS 
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deadstart tape, product tape, test tape and the build 
levels of various products. The information concerning 
how many products are displayed controlled by the 
information level parameter. The default is the products 
that are built in NOS/VE development. 

Note : The product level represents all of the 
Sunnyvale products. 

display build information 

build level : list of name 
cycle level : list, range of integer 
information level : key 
list : file 

development base : file = .intve 
status : status 

build level : bl : specifies the build level for which 

build information is displayed. 

Omission causes the build level to be used from the 
OS source library. 

cycle level : cl : specifies the cycle level for which 

build information displayed. Cycle level is the XX 
part of build number build_lXX07 for instance. All 
build levels for that cycle are displayed. 

Omission causes no cycle level to be selected. 

information level : il : specifies amount of information 
display for each build level, valid entries are full 
and brief. Brief, will display the level of nos 

deadstart tape, product tape, test tape, ocu, cybil 
and scu while full will display all of the brief 

information plus the level of many more products. 

Omission causes BRIEF to be used. 

list I 1 : specifies the file to receive the information 
displayed. 

Default if omitted : $OUTPUT 

development base | db : specifies the catalog in which all 
products and build levels reside. 


Default if omitted : .INTVE 
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status : see NOS/VE error handling. 


3.2.10 DISPLAY FEATURE BUILD LEVEL (DISFBL) 


The purpose of this procedure is to show a user the build 
level at which a feature was built into the system. This 
is accomplished by expanding the build decks and searching 
for the feature in question. 

display feature build_level 
feature, f : name 
minimum build_level, mbl : name 
output, o : file = $reponse 
product name, pn : name 
status : var of status 

feature | f : This is the name of the feature to search 
for. 

minimum build level | mbl : This is the oldest level of 
the system that the feature COULD HAVE gone into. 

Default if omitted : BUILD 00000. 

output I o : This is the file to write the results onto. 

product name | pn : specifies the system or product to be 
used. 

status : see NOS/VE error handling. 


3.2.11 DISPLAY SYMBOL TABLE (DISST) 


This command invokes a utility that displays CYBIL 
symbol tables. This utility requires an object library or 
object file as input. The object file must be compiled 
with debug symbol tables. This is the default on the 
CYBIL command. To use compile source, specify P= 'CYBIL' 
OL : file name. 


During program execution, a local file name, PD, is 
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generated. This file name contains the directives to 
generate a graphic display of the types. 

To generate graphical display : 

1) REPF PD 

2) LOGOUT 

On 170 side : 

3) SES.FORMAT 1= PD LOCAL 

4) SES.PRINT LISTING 


display symbol table 
input : file 
output : file 
object_library : file 
module : name 
status : status 

input I i : specifies the file where the utility reads its 
input from. 

Omission causes $input to be used. 

output I o : specifies the file where the utility writes 
its output. 

Omission causes $output to be used. 

object library | ol : specifies the object library or file 
where the symbol tables are that are to be 
displayed. If it is an object library and no module 
name is specified, it defaults to the first module on 
the object library. 

Required parameter. 

module | m : selects what module on object library that 
the symbols will be displayed for. 

Omission causes the first module on an object library 
to be used. 


status : see NOS/VE error handling. 
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3.2.12 EDIT SOURCE (EDIS) 


This command can be used inside the 

Working Environment. 

This command is used to modify a deck that resides on 
the working source library. 

The result of the editing will appear on a new cycle of 
the working source library. 


edit source modification : name 
deck : name 
output : file 

working catalog : file or key none = none 
status : status 


modification | m : specifies the modification to be used 
for editing the decks. The modification must exist 
in state 0 on the working library. 

deck I d : specifies the deck to be edited. 

Omission will necessitate selection of the deck 
(deck) to be edited from within the editor via the 
Select Deck command. 

output I o : specifies the file to receive displays from 
the editor. 

Omission causes $OUTPUT to be used. 

working catlaog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.13 EXTRACT SOURCE (EXTS) 


This command can NOT be used inside the 
Working Environment. 

This command is used to extract decks from the feature 
or system/product level to the working level in 
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preparation for making changes. In addition to the decks 
themselves, the relevant "parts" of all associated 
modifications, features and groups are extracted (i.e. 
SCU's EXTRACT_SOURCE_LIBRARY facility is used). 

If a deck does not exist at the feature level it is 
first extracted from the system/product level to the 
feature level. 

This extraction is performed using deck interlocks. 

The new version of an affected source library is 
written as the next cycle of the corresponding file. 

At least one of the deck and selection criteria 
parameters must be provided. If both are given the deck 
parameter is processed first. Currently a deck name MUST 
be specified. 

When extracting a deck without interlock, the deck is 
extracted at specified build level. If build level is 
specified as none, the deck is extracted with all active 
lines, as if it was extracted with interlocks. Decks 
extracted without interlock can not be transmitted back to 
integration or a feature catalog. 


extract source deck : list of name 
interlock : boolean 
selection criteria : file 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
working catalog : file or key none = none 
status : status 


deck I decks | d : specifies the decks to be extracted. 

interlock | i : specifies whether decks are to be 
extracted with or without interlocks. 

Omission causes TRUE to be used. 

selection criteria | sc : specifies the file containing 
SOU selection criteria commands that alone or in 
conjunction with the decks parameter select the decks 
to be extracted. 
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Omission causes $NULL to be used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build_level | bl : specifies the system or product level 
to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.14 FORMAT SOURCE (FORS) 


This command can be used inside the 

Working Environment. 

This command formats a CYBIL or SCL PROCEDURE source 
deck. 

If an error is detected, the replacement is 
suppressed. 


format cybil source deck : name 
modification : name 

working catalog : file or key none = none 
status : status 


deck I d : specifies the deck to be formatted. 

modification | m : specifies the modification under which 
the update is to be made. The modification must 
exist in state 0 on the working source library. 
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working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.15 GENERATE PRODUCT SET TAPE (GENPST) 


This procedure is used to generate product set tapes 
for dedicated machine time. The following is performed to 
create the tape : 


1. Make a copy of the installation table from the 


working, feature, 

installation catalog. 

2. IF product = 'ALL' THEN 

Change the product 
products defined 

raf$nos_ve_products. 
IFEND 

3. Change all the required 
'GENPST'. 


os build level or 


name to 

'GENPST' 

for 

all 

by 

the 

variable 

products 

product 

name 

to 


4. Change the path descriptor for all products 
specified by the product name and path parameter. 
Also change the product name to 'GENPST'. 


5. Delete all entries in the installation table that do 
not have have the product name 'GENPST'. And 
combine all product with an object library format 
from the build level, feature, and working catalogs, 
with the exception of bound products. 

6. Assemble release materials for the product 

'GENPST'. 


7. Generate the product tape. 

8. Verify the tape with the restore permanent files 

command. Dependent upon the value of the 

verify tape parameter. 

9. Delete the installation catalog dependent upon the 
value of the save installation table parameter. 
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generate_product_set_tape 

os build level, obi : name 

product name and path, pnap : list 1..$max value sets 
1..2 of any 

product_tape_type, ptt : key required, all = all 
verify tape, vt : boolean = true 

installation catalog, ic : file = 

$user.installation_catalog 

save installation catalog, sic : boolean = false 
external vsn, evsn : list of string 1..6 = $required 
type, t : key mt9$800 mt9$1600 mt9$6250 = mt9$1600 
delete modules, dm : file = $local.$null 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog, fc : file or key none = none 
feature build level, fbl : name = object 
working catalog, wc : file or key none = none 
working build level, wbl : name = object 
status 

os build level | obi : specifies the os build level. 

product name and path | pnap : specifies additional 
products or changed path names for included 
products. Both the product and path_name must be 
specified. 

product_tape_type | ptt : specifies the type of product 
set tape to be generated (required or all). Required 
is a subset of all. 

verify tape | vt : specifies rather to verify the tape or 
not. 

installation catalog | ic : specifies the location of the 
installation 

catalog that is being built. 

save installation catalog | sic : specifies rather to save 
the installation table or not. 

external vsn | evsn : specifies the external vsn on the 
product tape. 

type I t : specifies the product tape's density and 
format. 
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delete modules | dm : specifies file containing one or 
more lines each of which is a module deletion 
directive. See delete modules parameter in 
Link Operating System command for directive format. 

Omission causes no modules to be deleted. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name 1 pn : specifies the product catalog to be 
used. See working environment conventions for 
details. 

Default if omitted : w-e defaults. 

build level | bl : specifies the version of the product to 
be used. 

Default if omitted : w-e defaults. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

feature_catalog | fc : specifies the feature catalog to be 
used. 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build_level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.2.16 GET SOURCE (GETS) 


This command can be used inside the 

Working Environment. 
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This command writes one or more decks to a legible 
file. The decks may be written in expanded (EXPAND DECK) 
or unexpanded (EXTRACT DECK) form. 

The decks are taken from the Source Library without 
interlocks, thus allowing the user to include (or exclude) 
any modifications or features desired. This command 
allows the user to look at source that may already be 
interlocked by someone else, for informational purposes 
only, or for editing by a non-SCU editor. 

At least one of the deck and selection_criteria 
parameters must be provided. If both are given the deck 
parameter is processed first. 


NOTE : See the compile source write up for how decks are 
selected and how the selection criteria files are 
processed. 

CAUTION : Because get_source can be used to get a source 
module from a library without all active lines, 
caution must be exercised when using get source and 
replace source to get a module from a library, modify 
it and replace it back on the library. The 
replace_source procedure uses the 

generate_scu edit commands command to produce the 
changes necessary to the module on the source library 
to make it look like the modified version. If the 
module modified was not pulled off with all active 
lines, this would have the effect of deleting all 
changes made after the build level used and all code 
not currently in a build level that is not part of 
features or modifications specifically included (code 
at state 0 or 1). When doing something like this, 
BL= NONE and FEATURE= ALL must be specified on the 
get source command to retrieve the module from the 
library with all active lines. 

get_source 

deck : list of name 
source : file 
selection criteria : file 
feature : list of name 

expand : boolean or key forced expand, fe = false 

expansion depth : integer 

alternate product : list of list of name 

alternate base : list of file 

development base : file = .intve 
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target_operating_system : key 

line identifier, li: key right, r, left, 1, none = 
none 

development base, db: file = .intve 
product name : name = os 
build_level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build level : name = object 
status : status 


deck I decks | d : specifies the decks to be written. 

source | s : specifies the file to receive the decks. 
Omission causes source to be used. 

selection criteria | sc : specifies the file containing 
SCU selection criteria commands that alone or in 
conjunction with the decks parameter select the decks 
to be written.1ST 

Omission causes $NULL to be used. 

See the compile source write up for a more detailed 
explanation of this parameter. 

feature | f : specifies what features are to be included 
when compiling specified decks. The keywords ALL or 
NONE are also allowable values. 

Omission causes file WEF$FEATURE LIST in user's 
working catalog to be used if it exists. This file 
is maintained by the ASSIGN_MODIFICATION 
procedure. 

See the compile source write up for a more detailed 
explanation of this parameter. 

expand | e : specifies whether the decks are to be 
expanded. The FORCED EXPAND attribute will cause 
normally non-expandable decks to be expanded. The 
FORCED EXPAND selection may not be used while within 
the working environment (ENTWE). 

Omission causes FALSE to be used. 


expansion depth | ed : specifies the number of levels of 
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COPY and COPYC directives to process. 

Omission causes $max integer to be used. 

alternate_product | alternate_products | ap : specifies 
other product catalogs in which to find 
source_libraries to be used as alternate_bases in the 
expansion of the code. This parameter accepts either 
single names or pairs or names as values. If an 
entry is a single value, it specifies an alternate 
product name. If a pair of values is specified, the 
second element specifies the build level for the 
alternate product. If the second value is NONE or 
only a single value specified, a build level of NONE, 
which is all active lines at state 2 or higher is 
assumed. 

Omission causes no alternate_products to be 
accessed. 

alternate_base | alternate_bases | ab : specifies other 
files that may be required to properly expand the 
desired decks. 

Omission causes NONE to be used. 

target operating system | tos : specifies which 170 system 
to generate a 180 system for. The only valid values 
are NOS and NOS/BE. 

Omission causes NOS to be used. 

line identifier | li : This is the scu line identifier 
option. It can cause modset/line-number information 
to be produced for each line in a deck and on either 
the left or right side of a page. 

Omission causes no identifiers to be externalized. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build_level | bl : specifies the system or product build 
level to be used. 
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feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build level | wbl : specifies the working build 
level to be used. 


status : see NOS/VE error handling. 


3.2.17 MAKE BUILD JOBS (MAKBJ) 


This procedure generates a set of batch jobs to 
recompile a selected set of decks. The procedure will 
sort the selected list of decks by destination object 
library and by processor type and generate one batch job 
for each destination library. Within the batch job, there 
will be one section for each processor type. Decks can be 
selected by any valid scu selection criteria file 
directives. These directives are input on the 
selection criteria parameter. It is recommended that any 
common decks have a 'include copying decks' entry so that 
the full scope of effect is realized. Likewise, it is 
recommended that the 'include modified decks' entry have 
the include copying decks parameter set to true. All jobs 
will be created in a catalog called the 
build job catalog. This catalog will also contain the 
job logs after the jobs finish executing. This catalog 
will also contain a special file called the status_file 
(after release 121). This file contains a set of entries 
which will list a job's current status. This file can be 
read by the build exec procedure or manually. The batch 
jobs will be created to run in the current usernumber. 
They will have all of the working environment's 
environment variables set to the values supplied to 
make build jobs itself. 

make build jobs 

selection criteria | sc : file = $required 

list I 1 : file = $null 

cybil list options | do : list of key a, f, o, r. 
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ra, s, X, none = none 

save listings, save listing | si : key all, none, 

good, fatal, warning = none 

build_job_catalog | bjc : file = $optional 

submit_jobs | submit_job | sj : key immediate, i, 

delay, d, no_submit, ns = no_submit 

micro fiche | mf: boolean = false 

job_class I jc: any of key none, keyend, name, anyend 
= none 

compiler options | co: list of list 1..2 of string = 
$optional 

os build level | obi : name = $optional 
development base | db : file = .intve 
product name | pn : name = os 
build level | bl : name = $optional 
feature catalog | fc : file or key none = none 
feature build level | fbl : name = object 
working catalog | wc : file or key none = none 
working build level | wbl : name = object 
password | pw : name = $required 
status : var of status = $optional 

selection criteria | sc : This parameter is used to select 
which decks to compile. 

list I 1 : This parameter is passed to compile source to 
use as it's list parameter. 

cybil list options | do : This parameter specifies the 
values to use as list options when compiling cybil 
decks. 

save listings | save listing | si : This value is passed 
to the compile source parameter. 

build_job_catalog | bjc : This parameter specifies a 
scratch catalog that the procedure is to use to sort 
all of the decks selected. WARNING - IT IS CRITICAL 
THAT THIS PARAMETER BE A SCRATCH CATALOG. THE 
CATALOG SPECIFIED ON THIS PARAMETER MAY NOT HAVE ANY 
ITEMS WHICH THE USER WISHES TO KEEP AS THE PROCEDURE 
WILL DELETE THE ENTIRE CONTENTS OF THIS CATALOG. 

submit jobs | submit job | sj : This parameter controls 
automatic job submission. jobs can either be 

submitted automatically or manually. The value of 
'delay' causes all jobs to be created with the 
job class of maintenance. This allows these jobs to 
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be submitted but not initiated until that job class 
is opened for use by the operators (usually at night 
when the jobs won't compete with interactive users 
for machine resources). 

micro_fiche | mf : This selects the special operations 
required to create jobs that will produce 

microfiche-able listings. 

job_class I jc : This allows the user to select any job 
class desired. The default is the users default job 
class. 

compiler options | co : This allows a user to select the 
options (such as 'DA=ALL', 'OPT=LOW', etc.) for a 
compiler. This parameter has two string components. 
The first is the compiler - such as 'CYBIL', 

'FORTRAN'; etc. The second is the parameter options 
to be passed to COMPILE SOURCE when this compiler is 
to be used. The default if omitted is integration's 
standard parameters. 

os build level | obi : This specifies the level to use 
when the product name is set to something other than 
os. (Non-os products automatically have an 
alternate_base of os.) 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build level | 


wbl : specifies the working build 
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level to be used. 

password | pw : The password for the current user number. 
(All jobs are created to run under the current user 
number.) 


3.2.18 MAKE BUILD REQUEST (MAKER) 


This command is used to request that a feature(s) be 
considered for a subsequent build. This command generates 
a build request form to be signed by your manager, after 
it is signed it should be put in the DCT input basket. 

When specifying more than one feature per build request 
each feature is processed individually, creating a 
separate build request form for each. Also note that with 
multiple feature lists, parameters : modifications, 
dependencies and associated_srb_feature cannot be used. 
If these parameters are needed list features individually, 
making several requests. 

When making a build request, all code that the request 
affects must have already been transmitted to 
integration. After that has been done the 
MAKE BUILD REQUEST procedure is run. It will produce a 
form detailing all elements which have been selected, 
print one copy and retain a copy in the user's catalog in 
the subcatalog BUILD_REQUEST_CATALOG under the feature 
name as a file. These files are saved in case the build 
request form is lost, delete them after you get the form. 
The procedure will also put information into the 
provisional build content files in the product sub-catalog 
of INTVE. The DCT determines what build the code will go 
into. 

When a transmittal requires a change to the external 
system specifications, you will have to follow the 
following steps : 

1. Create a deck of text which contains the SRB item. 
This deck is created just like any new code deck. 

2. Transmit the SRB change to product name = 
SYSTEM_DOCUMENTATION. ~ 

3. Transmit the code to the appropriate product 
catalog. 
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4. Run MAKE_BUILD_REQUEST for your SRB transmittal. 

5. Run MAKE BUILD REQUEST for your code transmittal and 
specify the feature name used for the SRB 
transmittal as the ASSOCIATED_SRB_FEATURE. The SRB 
transmittal should use the same feature name. 

This general sequence should be followed whenever a 
code transmittal requires a documentation change, as 
well. 

make build request 

features : list of name 
modifications : list of name 
rebuild message_templates : boolean 
rebuild keypoint descriptors : boolean 
dependencies : list of name 
associated_srb_feature : name 
comments file : file 
development base : file = .intve 
product name : name = os 
author : string = $job(user) 
status : status 

features | feature | f : This parameter specifies the 
feature(s) which are ready to put in a build. All 
modifications that are members of the selected 
feature(s) are selected. 

Required parameter. 

modifications | modification | m : This parameter is used 
to specify a selected subset of the modifications 
from a feature which are ready to put in a build. 
This parameter would be used when doing a subsequent 
request for the same feature name. The build 
requests for a feature are cumulative. 

Omission causes all modifications to be selected. 

NOTE : When specifying more than one feature, this 
parameter cannot be used. 

rebuild message templates | rmt : This parameter sends a 
note to integration stating that message templates 
must be rebuilt when this code is integrated. 

Omission causes FALSE to be used. 


rebuild keypoint descriptors | rkd : This parameter sends 
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a note to integration stating that the keypoint 
descriptor file must be rebuilt when this code is 
integrated. 

Omission causes FALSE to be used. 

dependencies | dependency | d : This parameter sends a 
note to integration to make sure that the specified 
build requests have already been put into this or a 
previous build. 

Omission indicates no dependencies. 

NOTE : This parameter can not be specified when more 
than one feature is specified. 

associated srb feature | asf : This parameter specifies 
the feature name of an associated SRB item. 

Omission causes no SRB feature name to be listed. 

NOTE : When specifying more than one feature, this 
parameter cannot be used. 

comments file | cf : This parameter specifies a file 
containing additional comments to be sent to 
integration. 

Note : You should not specify an interactive file 
since you cannot supply it with an EOF when you 
are done. 

Omission is no comments. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name 1 pn : This parameter specifies the product 
name for which the build request is made. 

author | a : This parameter specifies the originator of 
the request. 


status : see NOS/VE error handling. 
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3.2.19 QUERY DEBUG TABLE (QUEDT) 


This command allows the user to interactively 
interrogate the debug file produced by 

link operating system. The user types in a PVA, procedure 
or variable name. The procedure responds with the 
procedure name and offset or the PVA respectively. 

query_debug_table 

debug_table, dt : file or key system, s, 

running system, rs, boot, b = system 
input : file 
output : file 

development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build level : name = object 
status : status 

debug_table | dt : specifies the debug table (output by 
link operating system) to be used for date. The 
keywords SYSTEM, S, RUNNING_SYSTEM, RS, BOOT and B, 
are also allowable values. If SYSTEM or S is 
specified, the procedure finds the proper debug table 
in the working catalog, feature catalog or build 
catalog. If RUNNING SYSTEM or RS is specified, the 
debug table of the running system is used. If the 
BOOT or B options are specified, the 
boot debug table, from the appropriate place, will be 
used. 

Omission causes SYSTEM to be used. 

input I i : specifies the file from which input commands 
are read, i.e., a PVA or procedure or variable name. 

Omission causes standard input to be used. 

output I o : specifies the file to which output is 
written. 

Omission causes output to go to standard output. 


development base | db : specifies the catalog in which all 
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products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the product catalog to be 
used. See working environment conventions for 
details. 

Default if omitted : w-e defaults. 

build_level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.2.20 RE EXTRACT SOURCE (REES) 


This command cannot be used inside the working 
environment. 

This command extracts the selected modifications and 
decks from the caller's working source library, extracts 
the decks with or without interlock from the product 
source library and reapplies the selected modifications on 
the caller's working source library. If there are any 
problems reapplying the modifications, that modification 
has to be reapplied manually. Modifications being 
reapplied are saved in the re extract subcatalog in the 
working environment. When satisfied that the 
modifications are reapplied properly, the re extract 
subcatalog should be deleted. 


The decks selected for reextraction can be specified 
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directly with the deck parameter or implicitly with the 
feature and modification parameters. If the deck 
parameter is not specified, the decks reextracted are the 
ones affected by the selected modifications. Specifying 
decks on the deck parameter selects only those decks. 

The modifications selected for reextracting are 
explicitly selected by the feature and modification 
parameters and implicitly selected by the deck parameter. 
If neither feature nor modification parameter is 
specified, all modifications at state zero in specified 
decks are reextracted. Specifying only the feature 
parameter selects only modifications that belong to the 
specified feature. Specifying only the modification 
parameter selects only those modifications. If both the 
feature and modification parameter are specified, only the 
specified modifications that belong to the specified 
features are selected. In all cases, only modifications 
at state zero are selected. 

If reextracting without interlocks, the build level 
parameter affects what source lines are extracted in the 
same way as in extract source without interlocks. 

NOTE : At least one of the feature, deck, or 
modification parameters must be specified. 

re_extract_source 

features : list of name 

decks : list of name 

modifications : list of name 

interlock : boolean 

development base : file = .intve 

product name : name = os 

build level : name 

feature catalog : name 

working catalog : name 

status : status 

features | feature | f : specifies what features are to be 
reextracted. 

Omission causes the selected decks and modifications 
to be determined by the deck and/or 
modification parameters. 

decks I deck : specifies what decks 
reextracted. 


are 


to be 
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Omission causes the selected decks to be determined 
by the feature and/or modification parameters. 

modifications | modification | m : specifies what 
modifications are to be reextrcted. 

Omission causes the selected modifications to be 
determined by the feature and/or deck 
parameters. 

interlock | i : specifies whether the deck is to be 
interlocked when reextracting. 

Omission causes the decks to be reextracted with 
interlocks. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.21 REPLACE SOURCE (REPS) 


This command can be used inside the 
Working Environment. 

This command is used to update a deck on the working 
source library. The new version of a deck on a file is 
compared with the old version on the working library using 
SCU's generate scu edit commands facility. The SCU editor 
is then invoked to apply the resulting edit commands. 
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This command, in conjunction with the get source 
command, provides the mechanism for making changes to a 
deck that are difficult to make by direct use of the SCU 
editor. The best example of this is automated formatting 
of source code. 

The new version of the working source library is 
written as the next cycle of the file. 


CAUTION : Because get_source can be used to get a source 
module from a library without all active lines, 
caution must be exercised when using get source and 
replace source to get a module from a library, modify 
it and replace it back on the library. The 
replace_source procedure uses the 

generate scu edit commands command to produce the 
changes necessary to the module on the source library 
to make it look like the modified version. If the 

module modified was not pulled off with all active 
lines, this would have the effect of deleting all 
changes made after the build level used and all code 
not currently in a build level that is not part of 
features or modifications specifically included (code 
at state 0 or 1). When doing something like this, 
BL= NONE and FEATURE= ALL must be specified on the 
get source command to retrieve the module from the 
library with all active lines. 

replace_source 

source : file 
deck : name 
modification : name 

working catalog : file or key none = none 
status : status 


source | s : specifies the file which contains the new 
version of the deck. 

deck I d : specifies the deck to be updated. 

modification | m : specifies the modification under which 
the update is to be made. The modification must 
exist in state 0 on the working source library. 


working catalog | wc : specifies the working catalog to be 
used. 
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status : see NOS/VE error handling. 


3.2.22 TRANSMIT TO FEATURE CATALOG (TRATFC) 


This command can NOT be used inside the 
Working Environment. 

This command transmits code (decks, modifications, 
features) from a working catalog to a feature catalog. 

Once the transmitted code has been written to its 
destination, it is removed from its source. The new 
version of an affected source library is written as the 
next cycle of the corresponding file. 

At least one of the deck, modification, or feature 
parameters must be provided. If more than one of them is 
given they are processed in the order just listed. 

Unlike when directly using SCU, e.g. in a selection 
criteria file, selecting a modification or feature via 
this commands parameters will result in selection of all 
decks affected by that modification or feature. 


transmit to feature catalog 
decks : list of name 
modification : list of name 
feature : list of name 

feature catalog : file or key none = none 
working catalog : file or key none = none 
status : status 


deck I decks | d : specifies the decks to be transmitted. 

modification | modifications | m : specifies the 
modifications to be transmitted. 

feature | features | f : specifies the features to be 
transmitted. 

feature_catalog | fc : specifies the feature catalog to be 
used. 
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working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


3.2.23 TRANSMIT TO INTEGRATION (TRATI) 


This command can NOT be used inside the 
Working Environment. 

This command transmits code (decks, modifications, 
features) from a working catalog to a feature catalog (if 
specified) and then integration. (If no feature catalog 
is used, it will transmit directly to integration.) 

Once the transmitted code has been written to its 
destination, it is removed from its source. The new 
version of an affected source library is written as the 
next cycle of the corresponding file. 

The deck, modification or feature parameter must be 
provided. Unlike when directly using SCU, e.g., in a 
selection criteria file, selecting a modification or 
feature via this command's parameters will result in 
selection of all decks affected by that modification or 
feature. When the appropriate decks are subsequently 
deleted from the working source library ALL mods contained 
in those decks are also deleted. Thus, if there are 
modifications you are still working on, the modification 
should be extracted and saved and deleted from the source 
library before transmitting the deck. 


transmit to integration 

decks : list of name 
modification : list of name 
feature : list of name 
development base : file = .intve 
product name : name = os 

feature catalog : file or key none = none 
working catalog : file or key none = none 
status : status 


deck I decks | d : specifies the decks to be transmitted. 
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modification | modifications | m : specifies the 

modifications to be transmitted. 

feature | features | f : specifies the features to be 
transmitted. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name ! pn : specifies the system or product to be 
used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. This parameter is ignored if a feature catalog 
is used. 

status : see NOS/VE error handling. 


3.3 PRODUCT SPECIFIC COMMANDS 


All of the procedures in this section are specialized. 
They only work on one particular product. Most of these 
are linking/binding procedures. Also included procedures 
used to generate one flavor of deadstart tape (GENDF and 
BUICT). Each procedure in this set expects that when 
called; the user's product name is set to the product for 
which the procedure is intended and that build level 
values reflect those for the appropriate product. 


3.3.1 BIND AV (BINA) 


The purpose of this procedure is to bind the AV 
product. 

bind av 

os build level, obi : name 
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cybil level, cl : name 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 

CYFSRUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 


delete_modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build level | wbl 
level to be used. 


specifies the working build 


status : see NOS/VE error handling. 
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3.3.2 BIND DE (BIND) 


This procedure will bind the Desktop using only 

information obtained from the ty The object libraries are 

merged using Merol so developers can use this to genera 

bind_de 

os build level, obi : name 

cybil level, cl : name = $optional 

development base, db : file = .intve 

delete modules, dm : file 

build level, bl : name = $optional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = $optional 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 

CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 
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feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


3.3.3 BIND HPA (BINH) 


The purpose of this procedure is to bind the HPA product, 
bind hpa 

os build level, obi : name 
cybil level, cl : name 
common level, cml : name 
bound_product, bp : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 
CYFSRUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

common level | cml : This is the level of the sunnyvale 
product COMMON'S MLF$LIBRARY to be used. 


Default if omitted 


selected from the os build 
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level's tying file entry. 

bound product | bp : This is the location to place the 
link results. 

Default if omitted : <wc>.BOUND_PRODUCT 

map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.4 BIND KERMIT (BINK) 


This procedure will bind the kermit product and use the 
tying file to determine where to obtain the required 
files. 

bind kermit 

os build level, obi : name 
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cybil level, cl : name = Soptional 

bound kermit, bk : file = $optional 

map, m : file = $optional 

delete modules, dm : file 

build level, bl : name = $optional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = $optional 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 
CYFSRUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

bound kermit | bk : The file to put the newly created 
kermit bound product onto. 

map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 


delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 
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working build level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


3.3.5 BIND MAILVE 


The purpose of this procedure is to bind the MAILVE 
product. 

bind mailve 

os build_level, obi : name 
tdu level, tl : name 
cybil level, cl : name 
bound_product, bp : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

tdu level | tl : This is the version of the screen manager 
code to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

cybil level | cl : This is the version of the 

CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 


bound product | bp : This is the location to place the 
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link results. 

Default if omitted : <wc>.BOUND_PRODUCT 

map j m : This is the location to place the linkmap. 

Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build_level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.6 BIND MALET (BINM) 


The purpose of this procedure is to bind the MALET 
product. 

bind malet 

os build level, obi : name 
cybil level, cl : name 
bound_product, bp : file 
map, m : file 
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delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil_level | cl : This is the version of the 

CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

bound product | bp : This is the location to place the 
link results. 

Default if omitted : <wc>.BOUND_PRODUCT 

map I m : This is the location to place the linkmap. 

Default if omitted : <wc>.MAINTENANCE.MAP 

delete_modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 


working catalog | wc : specifies the working catalog to be 
used. 
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working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.7 BIND MENU VE (BINMV) 


The purpose of this procedure is to bind the MENU VE 
product. 

bind menu ve 

os build level, obi : name 
cobol level, cl : name 
bound library, bdl : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cobol level | cl : This allows the user to select the 
cobol level to match with the new product. 

Default if omitted : cobol level from the tying 
f ile. 

bound library | bdl : This is the location to place the 
link results. 

Default if omitted : <wc>.BOUND PRODUCT 


map I m : This is the location to place the linkmap. 
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Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build_level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.8 BIND NAMVE (BINN) 


The purpose of this procedure is to bind the NAMVE 
product. The NAM/VE product consists of the object 
library osf$network management in an OS build catalog. 
The source is maintained on the OS source library. 

bind namve 

cybil level, cl : name 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : 


name 
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status : var of status 

cybil level | cl : This is the version of the 
CYFSRUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected build level. 

map I m : This is the catalog to place the linkmaps. 

Default if omitted : <wc>. MAINTENANCE. 

NETWORK_MAINTENANCE 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build_level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.9 BIND OCU (BINO) 


The purpose of this procedure is to bind the OCU product. 
The OCU product consists of the file 
OCF$OBJECT_CODE_UTILITY in an OS build level catalog. The 
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source is maintained on the OS source library 


bind_ocu 

cybil level, cl : name 
use_system_ocu, uso : boolean 
bound_product, bp : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working_build level, wbl : name 
status : var of status 

cybil level | cl : This is the version of the 
CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected build level. 

use system ocu | uso : This parameter specifies whether 
the link will be done using the standard ocu from the 
system or the the unbound ocu that is being linked. 

Default of omitted : the unbound ocu being linked. 

bound product | bp : This is the location to place the 
link results. 

Default if omitted : <wc>.OCU_BOUND_PRODUCT 

map I m : This is the location to place the linkmap. 

Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 
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feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.10 BIND PERFORMANCE TOOLS (BINPT) 


The purpose of this procedure is to bind the 
PERFORMANCE_TOOLS product. The PERFORMANCE_TOOLS product 
contains benchmark tests; including IBL, CBL and SBL. 

bind performance tools 

os build level, obi : name 

cybil level, cl : name 

bound product ring 3, bpr3file 

bound product ring d, bprdfile 

map, m : file 

delete modules, dm : file 

build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os_build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 
CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 
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bound product_ring 3 | bpr3 : This is the location to 
place part of the link results. 

bound product ring d | bprd : This is the location to 
place part of the link results. 

map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.11 BIND PETE (BINP) 


This is the front end for the pftf binding procedure 
supplied by the pftf group. This procedure will merge 
object libraries found in the working environment with the 
libraries in the pftf build catalogs and create the 
bound products with all the changes found. 

bind pftf 

os level, ol : name = Soptional 
os build level, obi : name 
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cybil level, cl : name = Soptional 

common level, cml : name = $optional 

bound pftf, bp : file = $optional 

bound pftf trace, bpt : file = Soptional 

map, m : file = Soptional 

delete modules, dm : file 

build level, bl : name = Soptional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = Soptional 

os level I ol : This allows the user to select the os 
system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 

CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 


working catalog | wc : specifies the working catalog to be 
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used. 

working build level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


3.3.12 BIND SCU (BINS) 


This command is used to merge and bind the pieces of the 
SOURCE CODE UTILITY. This command can be used inside of 
the working environment. 

bind_scu 

os level : name 

cybil level : name 

common level : name 

workbench level : name 

bound_product : file 

bound editor : file 

map : file 

editor map : file 

delete modules, dm : file 

development base : file = .intve 

product name : name = os 

build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build level : name = object 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : specifies the level of cybil to be used 
to satisfy external references. 

Default if omitted : derived from the TYING file 
contained in the os build level selected. 


common level | cml : specifies the level of common to be 
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used to satisfy external references. 

Default if omitted : derived from the TYING file 

contained in the os build level selected. 

workbench level | wl : specifies the level of workbench to 
be used to satisfy external references. 

Default if omitted : derived from the TYING file 

contained in the os build level selected. 

bound product | bp : specifies the location to place the 
results of the bind. 

Default if omitted : <working catalog>. 

<working build_level>. BOUND PRODUCT 

bound editor | be : specifies the location to place the 
results of the bind of the standalone editor. 

Default if omitted : <working catalog>. 

<working build level>. MAINTENANCE. 

0 S F $ C OMMAN D_LIBRARY 

map I m : specifies the location to place the bind map. 

Default if omitted : <working catalog>. 

<working_build_level>. MAINTENANCE.MAP 

editor map | em : specifies the location to place the 
editor's bind map. 

Default if omitted : <working catalog>. 

<working build level>. MAINTENANCE. 

EDITOR_MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 


product name | pn : specifies the system or product to be 
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used. 


Default if omitted : SCU 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build_level | wbl 
level to be used. 


specifies the working build 


3.3.13 BIND SVS (BINS) 


The purpose of this procedure is to bind the SVS product. 

bind SVS 

os build level, obi : name 

bound cptime, be : file 

bound kernel checker, bkc : file 

map, m : file 

delete modules, dm : file 

build level, bl : name 

feature_catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

bound cptime | be : This is the location to place part of 
the link results. 



User Documentation for Development on NOS/VE 


3-70 


Working Draft - Revision 7 

3.0 COMMANDS TO USE THE NOS/VE MAINTENANCE ENVIRONMENT 
3.3.13 BIND SVS (BINS) 


08/25/91 


bound_kernel checker | bkc : This is the location to place 
part of the link results. 

map 1 m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 


delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build_level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.14 BIND TDU (BINT) 


The purpose of this procedure is to bind the TDU product. 
bind_tdu 

os build level, obi : name 
cybil level, cl : name 
bound_product, bp : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
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working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil_level | cl : This is the version of the 
CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

bound product | bp : This is the location to place the 
link results. 

Default if omitted : <wc>.BOUND_PRODUCT 
map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 


delete_modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build level | wbl 
level to be used. 


specifies the working build 


status : see NOS/VE error handling. 
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3.3.15 BIND TDU POST PROCESSOR (BINTPP) 


This procedure will bind the tdu post processor and use 

the tying file to determine where to obtain the required 

files. 

bind_tdu_post_processor 

os build level, obi : name 

cybil level, cl : name = $optional 

bound product, bp : file = $optional 

map, m : file = $optional 

delete modules, dm : file 

build level, bl : name = $optional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = $optional 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. (which is the first os level that the product 
is introduced at). 

cybil level | cl : This is the version of the 
CYF$RUN_TIME_LIBRARY to use. 

Default if omitted : selected from the tying file of 
the selected os level. 

map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 

delete modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 
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feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


3.3.16 BIND TEST TOOLS (BINTT) 


The purpose of this procedure is to bind the TEST TOOLS 
product. 

bind_test_tools 

os build level, obi : name 
cybil level, cyl : name 1..11 
common level, cl : name 1..11 
bound_product, bp : file 
map, m : file 
delete modules, dm : file 
build level, bl : name 

feature catalog, fc : file or key none 
feature build level, fbl : name 
working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

os build level | obi : This allows the user to select the 
os system level to match with the new product. 

Default if omitted : os level is equal to the build 
level. 

(which is the first os level that the product is 
introduced at). 

cybil level | cl : This is the version of the 

CYFSRUN time library to use. 


Default if omitted : the value specified in the tying 
file of the selected os level. 
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common level | cl : This is the level of the sunnyvale 
product COMMON'S MLF$LIBRARY to be used. 

Default if omitted : selected from the os build 
level's tying file entry. 

bound product | bp : This is the location to place the 
link results. 

Default if omitted : <wc>.BOUND_PRODUCT 
map I m : This is the location to place the linkmap. 
Default if omitted : <wc>.MAINTENANCE.MAP 


delete_modules | dm : This is a list of object modules to 
delete from the INTEGRATION level of the unbound 
libraries. It does NOT delete modules from feature 
or working catalog level libraries. 

Default if omitted : nothing is deleted. 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 


working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.17 BUILD CIP TAPE (BUICT) 


The purpose of this procedure is to build a CYBER 
INTIAILIZATION PACKAGE (CIP) tape with the records 
produced by NOS/VE replaced with the versions from the 
specified build level. 
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build_cip_tape 

volume serial number, vsn : name 1..6 

machine_class, me : key of s0_51, s0_52, si, s2, s3, 

s4, s5, none = si 

output, o : file 

cip_file, cf : file 

build level, bl : name 

working catalog, wc : file or key none 
working build level, wbl : name 
feature catalog, fc : file or key none 
feature build level, fbl : name 
status : var of status 


volume serial number | vsn | This is the tape to write the 
CIP onto. Required parameter. 

machine class | me : This is version of CIP to produce. 

Default if omitted : SI. 

output I o : This is the file to write informative 
messages to. 

Default if omitted : $RESPONSE. 

cip file I cf : This is the file from which the non-NOS/VE 
portion of the cip information is taken. 


Default if omitted : From the appropriate cip 

catalog, with the build level selected from the TYING 

f ile. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 

level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 

level to be used. 


status : see NOS/VE error handling. 
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3.3.18 CREATE TEST TAPE (CRETT) 


This procedure creates the deadstart tape which contains 
the test base. 

create_test_tape 

rvsn : string = $required 
evsn : string = $required 
status : var of status = $optional 

rvsn : The internal vsn of the test tape. 

evsn : The external vsn of the test tape. 

status : See NOS/VE error handling. 


3.3.19 GENERATE CIP COMPONENTS (GENCC) 


The purpose of this procedure is to generate all of the 
CIP (Cyber Initialization Package) "pp" components needed 
for the CIP tape. The pp's are converted using 
BUILD CIP PP and the membory image components are 
converted using PACKAGE El. 

generate cip components 

version, v : integer 0..99999 
full build, fb : boolean 
build level, bl : name 

working catalog, wc : file or key none 
working build level, wbl : name 
feature catalog, fc : file or key none 
feature build level, fbl : name 
status : var of status 

version | v : This is the CIP version being built. 

full build Ifb : This controls whether pp's are to be 
selected from the master catalog (TRUE) as well as 
the feature and working catalogs (FALSE). 

build level | bl : specifies the system or product build 
level to be used. 
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feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.20 GENERATE DEADSTART FILE (GENDF) 


This command can NOT be used inside the 
Working Environment. 

This command puts together a file suitable for 
deadstarting NOS/VE using the output from calls to the 
LINK_OPERATING_SYSTEM command. 

The files needed for this operation are obtained by 
searching the build subcatalogs within the working catalog 
and feature catalog, and the operating system build 
subcatalog. If present, the files at the working and 
feature levels are subsets of the corresponding files at 
the integration level. 

generate_deadstart_file 

volume serial_number : string 
delete modules : file 
delete linked files : boolean 
cleanup_170 : key START END BOTH NONE 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = 
working build_level : name = object 
status : status 


none 
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volume serial_number | vsn : specifies the tape to which 
the deadstart file is to be written. 

delete modules | dm : specifies file containing one or 
more lines each of which is a module deletion 
directive. See delete modules parameter in 

Link Operating System command for directive format. 

Omission causes no modules to be deleted. 

delete_linked_flies | dlf : specifies whether the image 
file and the symbol table files created by the 
link operating system procedure are to be deleted 
after successful creation of a deadstart file. 

Omission causes TRUE to be selected. 

NOTE : If both the system core and job template are 
linked and this option set to true, next time 
this system is linked both system core and job 
templates have to be relinked even if only the 
job template portion is modified because the 
system core images and symbol tables have been 
deleted. If the system core files were saved in 
a feature catalog, or this option set to false, 
this would not be required if feature catalog 
specified on link. 

cleanup 170 | c7 : determines how 170 side files are 
transferred by the procedure. Allowable values are 
START, END, BOTH or NONE. Specifying START will move 
all files to the 170 side. Specifying END will purge 
all 170 side files when procedure completed, no files 
are moved to 170 side. BOTH moves the files to the 
170 side and purges them when the procedure 
completes. Specifying NONE will neither move files 
to the 170 side or purge them when the procedure 
completes. The parameter is of no use in normal 
development operations but is used by integration. 

Omission causes BOTH to be used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 


product name | pn : specifies the product catalog to be 
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used. See working environment conventions for 
details. 

Default if omitted : w-e defaults 

build_level | bl : specifies the system build level to be 
used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 


status : see NOS/VE error handling. 


3.3.21 GENERATE NOS DEADSTART TAPE (GENNDT) 


The purpose of this procedure is to produce a new NOS 
deadstart tape version from a previous version; adding 
files from the working environment. 

generate_nos_deadstart_tape 

old_nos_deadstart_tape, ondt : name 1..6 

new nos deadstart tape, nndt : name 1..6 

nos level, nl : string 4 

nos ve level, nvl : string 5 

print catalog, pc : boolean 

product name, pn : name 

build level, bl : name 

working catalog, wc : file or key none 
working build level, wbl : name 
status : var of status 

old nos deadstart tape | ondt : This is the VSN of the 
previous version of the NOS deadstart tape. 


new nos deadstart tape | nndt : This is the VSN of the new 
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version of the NOS deadstart tape. 

nos level | nl : This is the string containing the NOS 
level. All CMR decks are changed to display this at 
login. 

nos ve level | nvl : This is the string containing the 
NOS/VE level. All CMR decks are changed to display 
this at login. 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.22 LINK 170 


This procedure links 170 relocatable binaries which 
reside on the 170 libraries NOSBINS and NVELIB. The 
binaries used in linking are gotten from the working, 
feature, and product build levels of NOSBINS, NVELIB and 
NVEBINS. The linked object libraries and link maps are 
retrieved back to the 180 along with the dayfile of the 
170 partner job when linking completed. 

link_170 

module : key 
listing : file 

target_operating_system : key 
cleanup 170 : key 
full build : boolean 
build iiapas with debug : boolean 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = 


none 
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working catalog : file or key none = none 
status : status variable 


module | m : specifies the 170 module to be linked. Valid 
entries are DSMDSTG, DSMDST, DSMRUN, DSMTRM, IIAPAS, 
RHMPFP, RHAQAC, FMSLAVE, ALL (all 8), NONE. 

Required parameter. 


The keyword NONE merges the libraries OSF$NOSBINS, 
OSF$NVEBINS and OSF$NVELIB with the feature and 
build catalog version and saves the result 
libraries in the working catalog. The result 
library names are NOSBINS, NVEBINS and NVELIB. 

listing | 1 : specifies the 180 file to retrieve the 170 

link maps to. 

Omission causes the maps to be written to 'MAPS_170' 
in the 'maintenance' subcatalog of the working 
environment 

target_operating_system | tos : specifies the type of 170 
operating system the binaries are being linked for. 
Valid entries are NOS and NOSBE. 

Omission causes NOS to be used. 

cleanup 170 : this parameter allows a job to override the 
retrieval and replacing of the working catalog files 
for better performance when compiling and linking 
several 170 modules. It is not recommended that this 
parameter be used unless its use is fully understood 
with respect to COMPILE_SOURCE and GENDF. Valid 
entries are : 

START : replace files, do not retrieve results. 

END : do not replace files, DO not retrieve results. 
BOTH : replace files, retrieve results. 

NONE : do not replace files, do not retrieve 

results. 

Omission causes BOTH to be used. 


full build I fb : this parameter specifies whether 
complete libraries should be generated consisted of 
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the INTVE, feature and working catalog copies merged 
together. This parameter is intended for integration 
use. Most other users should use the default value. 
The merged copies are moved into the 
working catalog.working build level subcatalog. 

Omission causes FALSE to be used. 

build iiapas with debug | biwd : causes a debug version of 
IIAPAS (using NETIOD in place of NETIO) to be 
generated. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build_level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.23 LINK BOOT (LINE) 


The purpose of this procedure is to link the object 
libraries OSF$BOOT_JOB and OSF$BOOT_MONITOR. The results 
of this link is the BOOT MEMORY IMAGE file. 


link boot 
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display_options, do : key errors, e, full, f 

delete modules, dm : file 

build level, bl : name 

product name, pn : name 

feature catalog, fc : file or key none 

feature build level, fbl : name 

working catalog, wc : file or key none 

working build level, wbl : name 

status : var of status 

display options | do : This controls whether the link maps 
are retained always (FULL) or only if errors occur 
(ERRORS). 

delete modules | dm : This parameter allows the user to 
delete existing modules that may have been added from 
the integration copy of the files. 

build level | bl : specifies the system or product build 
level to be used. 

product name | pn : specifies the system or product to be 
used. 


feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 


working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 


status : see NOS/VE error handling. 


3.3.24 LINK ENVIRONMENT INTERFACE (LINEI) 


The purpose of this procedure is to link the library 
OSF$C170 El. This procedure then produces the 
environment interface that is placed on the CIP tape after 
being converted by BUILD CIP PP. 
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link environment interface 

display_options, do : key errors, e, full, f = errors 

delete modules, dm : file 

build level, bl : name 

product name, pn : name 

feature catalog, fc : file or key none 

feature build level, fbl : name 

working catalog, wc : file or key none 

working build level, wbl : name 

status : var of status 

display options | do : This controls whether the linkmaps 
are retained always (FULL) or only if errors occur 
(ERRORS). 

delete_modules | dm : This parameter allows the user to 
delete existing modules that may have been added from 
the integration copy of the files. 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


3.3.25 LINK OPERATING SYSTEM (LINOS) 


This command links the various components of the 
operating system. The components can be linked 
independently using output from previous calls to this 
command, or the entire operating system can be linked with 
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one call. 

The files needed for linking are obtained by merging 
files from build subcatalogs within the working catalog 
and feature catalog with the corresponding files in an 
operating system build subcatalog. If present, the files 
at the working and feature levels are subsets of the 
corresponding files at the integration level. 

NOTE : If both link system core and link job template 
are specified as false, osf$tasks and osf$builtin library 
are linked if it is necessary. 

link operating system 

link job template : boolean 
link_system core : boolean 
delete modules : file 

operating system identifier : string 1..5 
product set identifier : string 1..3 
debug : boolean 

display options : list of name 
page_size : integer 
page table length : integer 
development base : file = .intve 
product name : name = os 
build_level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = none 
working build level : name = object 
status : status 

link job template | Ijt : specifies whether a job template 
is to be linked. 

Omission causes TRUE to be used. 

link system core | Isc : specifies whether a system core 
is to be linked. 

Omission causes FALSE to be used. 

delete module | delete modules | dm : specifies a file 
containing one or more lines each of which is a 
module deletion directive. The format of these 
directives should be : 


delete module module status= ignore status 
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The status must be specified as shown. The 
directives are executed for each library in 
job template and/or system core and the module 
won't exist in all libraries. The Linker will 
issue a warning each time the module is "not 
found". If not specified in this manner the 
procedure will abort. 

Omission causes no modules to be deleted. 

operating_system identifier | osi : specifies the 

operating system part of the system header. 

Omission causes the build level to be used. 

product_set_identifier | psi : specifies the product set 
part of the system header. 

Omission causes SVL to be used. 

debug | d : specifies whether to include debug information 
(for use with dump analysis tools). 

Omission causes TRUE (include the debug information) 
to be used. 

display options | do : specifies whether the link map is 

saved or not. The options are errors, e, full or f. 

If errors is specified, the link map is saved fi 
there are linker errors. If no errors, the link maps 
are deleted. Specifying full saves link maps 

regardless of errors. 

Omission will cause the ALL option to be used. 

NOTE : When any option other than FULL is selected, 
the full maps produced by the linker are 

deleted. Also, the binary maps are created when 
any option other than FULL is selected. 

page size | ns : specifies the virtual memory page size to 
be used. 

Omission will cause the "standard" page size to be 
used. 

page table length | ptl : specifies the virtual memory 
page table length to be used. 
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Omission will cause the "standard" page table length 
to be used. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name ! pn : specifies the product catalog to be 
used. See working environment for details. 

Default if omitted : w-e defaults 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build_level | wbl 
level to be used. 


specifies the working build 


status : see NOS/VE error handling. 


3.4 EDITOR ORIENTED COMMANDS 


3.4.1 COPY BOX (COPB CB) 


The procedure is to be used in conjunction with the screen 
editor. After a user has marked a box of text; he can 
call this procedure to copy it to another portion of the 
screen. The cursor position is expected to be the upper, 
left hand, corner of the boxed text's new location. 
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copy_box 

status : var of status 
status : see NOS/VE error handling. 


3.4.2 DELETE BOX (DELB DB) 


This is a procedure for use with the screen editor. It 
will delete a block of text marked with the box mark key. 

delete_box 

status : var of status 
status : see NOS/VE error handling. 


3.4.3 MOVE BOX (MOVB MB) 


This procedure is used in conjunction with the screen 
editor. It will move a marked block of text. 

move box 

status : var of status 
status : see NOS/VE error handling. 


3.5 MISCELLANIOUS USEFUL PROCEDURES 


3.5.1 BACKUP USER CATALOG (BACUC) 


The purpose of this procedure is to perform a BACKUP_ 
PERMANENT FILES on a user's entire catalog and replace the 
resultant backup file to a 170 file called BACK180. 
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backup_user_catalog 

status : var of status 

status : see NOS/VE error handling. 


3.5.2 CATALOG MULTI RECORD TAPE (CATMRT) 


This procedure will list the contents of a NOS/VE or CIP 
deadstart tape. 

catalog_multi_record_tape 

external_vsn, evsn : name = $required 

kind, k : key of, sO cip, cip, nos ve = $required 

type, t : key of, mt9$800, mt9$1600, mt9$6250 = 

mt9$6250 

output, o : file = $response 
status : var of status = Soptional 

external vsn | ev : The vsn of the tape to catalog. 

kind I k : The expected data on the tape. 

type I t : The tape density. 

output I o : The file to write the listing onto, 
status : See NOS/VE error handling. 


3.5.3 COMPARE CATALOG CONTENTS (COMCC) 


This is a utility procedure used to compare two NOS/VE 
catalogs. It will do a depth-first comparison and list 
any differences. 

compare catalog contents 
0catalog_l, cl : file = $required 

catalog 2, c2 : file = $required 
result, r : file = $response 
status : var of status 
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catalog 1 | cl 

: The 

first 

catalog 

to 

compare. 

catalog 2 | c2 

: The 

first 

catalog 

to 

compare. 

result 1 r : 

The 

file 

that recieves the difference 


listings. 

Note: the output is written to the END of 
this file. 

status : see NOS/VE error handling. 


3.5.4 COMPILE DECKS IN ISOLATION (COMDII COMPILE DECK IN ISOLATION) 


'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

DESCRIPTION NEEDED ««- 

'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

compile decks in isolation 

decks, deck, d : list of name or key all = $optional 
include decks file, .. 

include deck file, idf : file = $optional 
base, b : file = source library 

alternate base, ab : file or key none 

.intve.os.source_library 

width, w : integer 10..110 = 110 

list, 1 : file = $list 

status : var of status = $optional 

—» PARAMETER DESCRIPTIONS NEEDED «— 


status : See NOS/VE error handling. 


3.5.5 COPY NOS TAPE (COPNT) 


This is a utility procedure used to copy NOS deadstart 
tapes from the VE side. It will only work in dual-state 
mode. 

copy_nos_tape 

source vsn, svsn : name 1..6 
target vsn, tvsn : list of name 1..6 
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source_density, sd : key of, pe, ge = pe 
target_density, td : key of, pe, ge 
format, f : key of, i, si = i 
status : var of status 

source vsn | svsn : The label on the tape to copy, 
target vsn | tvsn : The label on the tape to copy to. 
source_density | sd : The bit density of the source tape. 
target_density | td : The bit density of the target tape. 

Default if omitted : source density, 
format | f : The NOS standard tape formats, 
status : see NOS/VE error handling. 


3.5.6 COPY NOS VE TAPE (COPNVT) 


This is a utility procedure used to copy NOS/VE deadstart 
and product tapes (ON NOS - this procedure only works on 
dual state machines - not standalone). 

copy_nos_ve_tape 

source vsn, svsn : name 1..6 
target vsn, tvsn : list of name 1..6 
source_density, sd : key of, pe, ge = pe 
target_density, td : key of, pe, ge 
status : var of status 

source vsn | svsn : The label on the tape to copy, 
target vsn | tvsn : The label on the tape to copy to. 
source_density | sd : The bit density of the source tape. 
target_density | td : The bit density of the target tape. 

Default if omitted : source density, 
status : see NOS/VE error handling. 
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3.5.7 COPY UNLABELLED TAPES (COPUT COPY UNLABELLED TAPE) 


This procedure copies unlabelled tapes on the 180 side by 
first requesting both the source tape and the target tape, 
then doing a COPY FILE on them. It has to copy the tapes 
file by file and it needs to write a tape mark on the 
target tape after every file. 

If a list is specified for the TARGET_VSN, the procedure 
will continue copying the remaining tapes if one of the 

tapes does not copy correctly. It will specify the 

external vsn of the bad tape and it will also return bad 
status. 

copy_unlabelled_tapes 

source vsn, svsn : name 1..6 = $required 
target vsn, tvsn : list of name 1..6 = $required 
type, t : key mt9$800, mt9$1600, mt9$6250 = mt9$6250 
status : var of status = Soptional 

source vsn | sv : The external name of the original tape. 

target vsn [ tv : The external name of the new copy. 

type I t : The tape density. 

status : See NOS/VE error handling. 


3.5.8 DELETE JOB (DELJ) 


The purpose of this procedure is to totally remove an 
entry for a job from a build job catalog. The following 
files are affected : 

1) The build job is deleted. 

2) The build job's job log is deleted. 

3) All entries for the job are removed from the status 
f ile. 

delete_j ob 

build_job_catalog, bjc : file 
job name, jn : name 
status : var of status 
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build_job_catalog | bjc : This is the catalog created by 
MAKE BUILD JOBS and which contains the status 
retrieval file that is to have it's entry removed. 

job name | jn : This is the entry to remove 

status : see NOS/VE error handling. 


3.5.9 DISPLAY CATALOG CONTENTS (DISCC) 


This is an alternative to the system's DISPLAY CATALOG 
command. This procedure will display subcatalogs in a 
breadth-first manner as opposed to the depth-first mode 
used by DISPLAY_CATALOG. 

display_catalog_contents 

catalog, c : file = $USER 
output, o : file = $OUTPUT 
status : var of status 

catalog | c : This is the catalog to display, 
output I o : This is the file to receive the display, 
status : see NOS/VE error handling. 


3.5.10 GET MULTI RECORD FILE (GETMRF) 


The purpose of this procedure is to retrieve NOS ULIB 
format files. 

get multi record file 

nos ve file, nvf : file 
nos file, nf : name 1..7 
development base : file = .intve 
status : var of status 

nos ve file | nvf : The 180 file name to retrieve the data 
to. 
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nos file | nf : The 170 file to retrieve. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

status : see NOS/VE error handling. 


3.5.11 GENERATE SCL LISTINGS (GENSL GENERATE SCL LISTING) 


The purpose of this procedure is provide headers for scl 
procedures which look like those from a compiler. 

generate scl listings 

scl command library, scl : file = $required 
listing file. If : file = $required 
status : var of status = $optional 

scl command library | scl : This is the object library 
that contains the scl procs which are to have headers 
put on their listings. 

listing file | If : This is the file to receive the 
listings (with headers). 

status : See NOS/VE error handling. 


3.5.12 REPLACE MULTI RECORD FILE (REPMRF) 


The purpose of this procedure is to send NOS ULIB format 
files to the 170 side of the system. 

get multi_record file 

nos ve file, nvf : file 
nos file, nf : name 1..7 
development base : file = .intve 
status : var of status 

nos ve file | nvf : The 180 file name to retrieve the data 
to. 
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nos file | nf : The 170 file to retrieve. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

status : see NOS/VE error handling. 


3.5.13 RESTORE USER CATALOG (RESUC) 


The purpose of this proc is to restore a users catalog 
from the backup file BACK180 saved on the 170-side. 
BACK180 is produced by BACKUP_USER_CATALOG (BACUC). 

restore_user_catalog 

status : var of status 

status : see NOS/VE error handling. 


3.5.14 SEQUENCE LIBRARY (SEQL) 


This is a utility procedure which is used during library 
cleanup. It is used by the update jobs to change 
modifications to state 4 and then resequence them. It 
should be used by development to perform the same task. 
This procedure expects to be executed from within the 
working environment (inside ENTWE). It will reference a 
file called SEQUENCE_LIST which exists on the INTVE 
product catalog which the user is using. This file will 
have the list of modifications to change to state 4. 

sequence_library 

status : var of status 


status : see NOS/VE error handling. 
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The procedures in the following section are not intended 
for direct use. This section of documentation is intended 
for procedure writers who may need to make use of one of 
these components. 


4.1 LANGUAGE PROCESSOR SUBROUTINES 


The purpose of the language processor subroutines are 
to provide compile source with a uniform interface to a 
set of "unusual" (mostly NOS-resident) languages which do 
not follow the NOS/VE System Interface Standards. Each of 
these procedures appears to compile source as a compiler 
for the language in question. Each procedure is 
responsible for massaging the input source text, moving 
files to the 170, initiating a 170 compile job and 
retrieving the compile status, "object" file/library and 
listings. The listings may be massaged to convert the 
header to 180 standards if they are destined to be placed 
on a listing library. Each 170 processor also 
communicates with compile source via some xdcl/xref'ed 
variables that control whather compile source should 
retrieve the result files. 

A second set of processor procedures exist for 180 
processes for which there is no compiler or for which some 
special manipulation must take place prior to 
compilation. Examples of the former are scl procedures 
and program descriptions. An example of the latter is 
generate command table module. 


4.1.1 CCL PROCEDURES 


This procedure puts a NOS/170 command langauge 
procedure onto a ULIB format library. 


ccl procedures 
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input : file 
list : file 
binary : file 

list options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 


4.1.2 CONVERT TEXT TO OBJECT 


This is a processor that will convert an object library, 
that has been encoded into a text deck as hex bytes, back 
into the object library again. 

convert_text_to_obj ect 
input : file 
list : file 
binary : file 

list options : list of name 

status : status : var of status = $optional 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. 

binary 1 b : This is the file where the result object 
library is to end up. 

list options | lo : This is a dummy parameter that is used 
to provide compliance with COMPILE SOURCE. It is 
ignored. 


status : See NOS/VE error handling standards. 



User Documentation for Development on NOS/VE 


4-3 


Working Draft - Revision 7 

4.0 SUBROUTINES 

4.1.3 CP COMPASS 


08/25/91 


4.1.3 CP COMPASS 


This is the standard NOS (or NOS/BE depending on the value 
of the wev$target operating system variable) compiler. 
Note : this procedure will satisfy external references 
from the following 'text' files which exist in the 170 
catalog pointed to by the tying file variable wev$nos base 
(or the NOS/BE psudo text files pointed to by 
wev$nosbe_base). 

cp_compass 

input : file 
list : file 
binary : file 

list_options : list of name 

get system text : list of name 

status : status : var of status = $optional 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

get system text | gst | g : Additional 'text' files from 
wev$nos base (or wev$nosbe base) to satisfy external 
references from. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
compass options are used - anything else is ignored. 

status : See NOS/VE error handling standards. 


4.1.4 CREATE FASLAVE (CREFS) 


The purpose of this procedure is to produce the deck 
components for FASLAVE. This procedure works in 
conjunction with a dummy deck that exists on os 
source library. This dummy deck has all of the attributes 
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needed to invoke this procedure when an attempt is made to 
compile it. This procedure will then compile the decks 
off of the FMA product and put them into NVERELS as 
required. 

create_faslave 

input, i : file = $local.$null 

binary, b : file = $local.$null 

list, 1 : file = $local.$null 

list options, lo : list of name = $optional 

status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling. 


4.1.5 CREATE MANUAL (CREM) 


The purpose of this procedure is to overlay the system 
standard CREATE MANUAL procedure with an interface which 
is compatable with COMPILE_SOURCE. 

create manual 

input, i : file = $local.$null 

binary, b, output, o : file = $local.$null 

error, e : file = $local.$errors 

list, 1 : file = $local.$null 

list options, lo : list of name = $optional 

status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
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compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

error | e : This is the file where all detected errors are 
listed. 

binary | b | output | o : This is the file where the 
result object library is to end up. The 'binary' 
parameter is supplied for compile source, the 
'output' parameter is supplied for compatibility with 
the standard create manual utility. 

list options | lo : This parameter selects whither a 
cross-reference is generated. The only valid values 
are 'R' and 'NONE'. Anything else is ignored by this 
procedure. 

status : See NOS/VE error handling. 


4.1.6 CREATE INSTALLATION TABLE (CREIT) 


This is a processor for COMPILE SOURCE. It is used to 

produce an installation table from a deck on the OS 

source library. 

create installation table 

input, i : file = compile 
binary, b : file = Igo 
list, 1 : file = $list 
list options, lo : list of name 
status : var of status 

input I i : The file containing the installation table 
source deck. 

binary | b : The destination file name for the 

installation table. 

list I 1 : This is the file which receives a display of 
the resultant installation table. 

list options | lo : This parameter is included for 
compatibility with other processors. It is ignored. 
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status : see NOS/VE error handling. 


4.1.7 CYBIL CC 


This procedure processes cybil cc procedures. Note : this 

procedure will use version of the cybil compiler from the 

wev$cybil cc base catalog. If target operating system is 
equal to NOS/BE, it will use the version from the 

wev$nosbe cybil cc base catalog. Also note that all 

cybil cc interface decks (LGxxxxx, BIxxxxx, DIxxxxx, 
etc.) need to be satisfied at expansion time, not at 
compilation time. It is recommended that users of this 
language specify ap=COMMON_170 on the compile source 
call. 

cybil_cc 

input : file 
list : file 
binary : file 

list options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
cybil options are used - anything else is ignored. 

status : See NOS/VE error handling standards. 


4.1.8 CYBIL OBJECT CHECKING 


This proccessor front ends the cybil processor then sets 
weak parameter checking on the modules generated. The 
cybil parameters parameter is a string that will contain 
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any parameters of cybil that the user wants to feed into 
cybil. When called from compile source, these parameters 
must be specified within double quotes, ie. corns 
p='cybil object checking cp=''opt=high rc=none da=all'''. 

cybil_object checking 
input : file 
binary : file 
list : file 

list options : list of name 
cybil parameters : string 
status : status 

input I i : This file contains the source text. 

binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
cybil options are used - anything else is ignored. 

cybil parameters | cp : This parameter allows the user to 
use any of the parameters of cybil that are not 
listed above. 

status : See NOS/VE error handling standards. 


4.1.9 DEFINE MULTI TERMINAL (DEFMT) 


The purpose of this procedure is to trick compile source 
into compiling terminal definition decks. This procedure 
will handle multiple definition decks on one input file. 

define multi terminal 

input, i : file = compile 
binary, b : file = Igo 
list, 1 : file = $list 
list option, lo : list of name 
status : var of status 
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4.1.9 DEFINE MULTI TERMINAL (DEFMT) 


input I i : This is the file which contains the source 
data. 

binary | b : This is the location to place the results. 

list I 1 : This is the file to receive the compilation 

listings. 

list option I lo : This parameter controls the items which 
appear on the listings. 

status : see NOS/VE error handling. 


4.1.10 DESKTOP CONFIGURATION (DESCF) 


The purpose of this procedure is to trick COMPILE SOURCE 

into creating desktop environment toolboxes from toolbox 

text 

desktop configuration 

input, i : file = $required 
binary, b : file = $required 
list, 1 : file = $NULL 

list options, lo : list of name = $optional 
status : var of status = $optional 

input I i : This file contains the source text. 

binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling. 
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4.1.11 DESKTOP CONTEXT (DESC) 


The purpose of this procedure is to trick COMPILE SOURCE 

into compiling desktop environment context files. 

desktop_context 

input, i : file = $required 
binary, b : file = $required 
list, 1 : file = $NULL 

list options, lo : list of name = $optional 
status : var of status = $optional 

input I i : This file contains the source text. 

binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling. 


4.1.12 DESKTOP TOOLBOX (DEST) 


The purpose of this procedure is to trick COMPILE SOURCE 
into creating desktop environment toolboxes from toolbox 
text 

desktop_toolbox 

input, i : file = $required 
binary, b : file = $required 
list, 1 : file = $NULL 

list options, lo : list of name = $optional 
status : var of status = $optional 

input I i : This file contains the source text. 
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binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling. 


4.1.13 FORTRAN CC 


This procedure processes FTN5 procedures. Note : this 

procedure will use the version of the fortran compiler 

from the system running on the 170. 

fortran cc 

input : file 
list : file 
binary : file 

list options : list of name 
optimization : integer 0..3 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
fortran options are used - anything else is ignored. 

optimization | opt | o : This parameter allows the user to 
specify the fortran optimization level to use. 

Default is set to two because opt level three is 
considered "potentially dangerous" in the FTN5 

manual. 
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status : See NOS/VE error handling standards. 


4.1.14 GENERATE COMMAND TABLE MODULE (GENCTM) 


This procedure causes an expanded deck with this processor 
to be put through a 'precompiler' before being sent 
through the standard cybil compiler. This precompiler 
changes the command table deck into a real cybil module. 

generate command table module 
input : file 
list : file 
binary : file 

list options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | list option | lo : This parameter allows 
the user to select the type of listing he prefers. 
Only standard cybil options are used - anything else 
is ignored. 

status : See NOS/VE error handling standards. 


4.1.15 GENERATE MSG TEMPLATE MODULE (GENMTM) 


This command is used to create an object file from 
message template definitions. 

This command utilizes the GENERATE_MESSAGE_TEMPLATE 
command to generate commands for the CREATE MESSAGE MODULE 
sub_utility of CREATE_OBJECT_LIBRARY. ~ ~ 


The message template source must be expanded and 
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enclosed by MODULE/MODEND statements before being used as 
input to GENERATE_MSG_TEMPLATE_MODULE. 

GENERATE_MESSAGE_TEMPLATE will then generate 

CREATE_MESSAGE_MODULE, CREATE_STATUS_MESSAGE and 

END_MESSAGE_MODULE commands. CREATE_OBJECT_LIBRARY is 
invoked, the subcommands are processed and a library is 
generated. 

generate msg template module 
input : file 
binary : file 
list : file 
errors : file 
product identifier : name 
list options : list of name 
status : status 

input I i : specifies the file which contains the expanded 
message template. 

binary [ b : specifies the file into which the compiled 
message template module will be placed. 

Omission causes $LOCAL.LGO to be used. 

list I 1 : specifies the file to which the compilation 

listings are to be written. 

Omission causes $LIST to be used. (Warning - in a 
batch job, $LIST is connected to OUTPUT. If a 
listing is not desired in a batch job, $NULL 
should be specified for list.) 

errors | e : specifies the file which contains errors 
encountered by GENERATE_MESSAGE_TEMPLATE. If this 
file is connected to $ERRORS, then this file will 
also contain errors encountered by 

CREATE_MESSAGE_MODULE subcommands (i.e., 

CREATE_STATUS_MESSAGE). 

Omission causes $ERRORS to be used. 

product identifier | pi : specifies the two character 
product name concatenated onto the module name 
generated by GENERATE_MESSAGE_TEMPLATE. 


Omission causes OS to be used. 
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list options | list option [ lo : specifies the list 
options to be used on the CYBIL call. (Warning - 
this parameter is ignored. Thus, the default options 
(S,R) are used.) 

status : see NOS/VE error handling. 


4.1.16 META 


This is the NOS META assembler, 
meta 

input : file 
list : file 
binary : file 

list options : list of name 
get system text : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling standards. 


4.1.17 PP COMPASS 


This is the processor procedure for NOS/VE pp drivers. 
Prior to 13500, this was a separate, modified, compass 
assembler. At NOS/VE 13500 (NOS level 51F3), this 
capability was added to the standard nos compass 
assembler. 



User Documentation for Development on NOS/VE 


4-14 


Working Draft - Revision 7 

4.0 SUBROUTINES 
4.1.17 PP COMPASS 


08/25/91 


pp_compass 

input : file 
list : file 
binary : file 

list options : list of name 
get system text : list of name 
name 170 : name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
compass options are used - anything else is ignored. 

get system text | gst | g : Additional 'text' files from 
wevSnos base (or wev$nosbe base) to satisfy external 
references from. 

name 170 | n : This parameter was used to allow the ident 
card value to be overridden. It is now obsolete, but 
is retained for backward compatability. 

status : See NOS/VE error handling standards. 


4.1.18 PROGRAM_DESCRIPTIONS (PROGRAM_DESCRIPTION, 

PROGRAM_DESCRIPTORS, PROGRAM_DESCRIPTOR, PROD) 

This procedure exists to put program descriptions, 
specified as text, onto object libraries. 

program descriptions 
input : file 
list : file 
binary : file 

list options : list of name 
status : status 
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input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 

status : See NOS/VE error handling standards. 


4.1.19 SCL PROCEDURES (SCL PROCEDURE, SCLP, SCL) 


This procedure puts VE command language procedures onto an 

object library. 

scl_procedures 

input : file 
list : file 
binary : file 

list options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 

ignored by this procedure. 


status : See NOS/VE error handling standards. 
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4.1.20 SYMPL 


This procedure will compile decks written in 170 SYMPL and 
put the results onto a ULIB object library. 

sympl 

input : file 
list : file 
binary : file 

list_options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
sympl options are used - anything else is ignored. 

status : See NOS/VE error handling standards. 


4.1.21 TEXTCODE TEXTFORM 


This procedure will "compile" decks written with 170 

textcode/textform embedded formatting directives. 

textcode textform 
input : file 
list : file 
binary : file 

list_options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 
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binary | b : This is the file where the result text file 
is to end up. 

list options | lo : This parameter is ignored. It only 
exists for compatibility with other processor types. 

status : See NOS/VE error handling standards. 


4.1.22 TEXT FILES 


The purpose of this procedure is to trick COMPILE SOURCE 
into generating text files instead of object libraries. 
Note: list options are ignored. The only purpose of this 
parameter is to provide easier interfacing with 
compile source. 

text files 

input, i : file = compile 
binary, b : file = Igo 
list, 1 : file = $list 

list options, lo : list of name = $optional 
status : var of status = Soptional 

input I i : This file contains the source text. 

binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 
ignored by this procedure. 


status : See NOS/VE error handling. 
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This procedure puts decks onto a 170 ULIB library as NOS 

"TEXT" type records. 

text_170 

input : file 
list : file 
binary : file 

list_options : list of name 
status : status 

input I i : This file contains the source text. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary | b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 
ignored by this procedure. 

status : See NOS/VE error handling standards. 


4.1.24 Z80 COMPASS 


This procedure uses a modified compass assembler to 
produce Z80 object code. It is used to produce the 
console drivers which use the CDC721 terminal as a 
console. It is also used by RAA's key utility. 

z80_compass 

input : file 
list : file 
binary : file 

list options : list of name 
status : status 

input I i : This file contains the source text. 


list I 1 : This is the file to put the listing onto. If 
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compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

binary i b : This is the file where the result object 
library is to end up. 

list options | lo : This parameter allows the user to 
select the type of listing he prefers. Only standard 
compass options are used - anything else is ignored. 

status : See NOS/VE error handling standards. 


4.2 MISCELLANIOUS SUBROUTINES 


The following is a list of subroutines for the main 
working environment procedures. This list is 
provided as a reference for procedure writers. 


4.2.1 ACQUIRE FILE (ACQF) 


The purpose of this procedure is to search a list of 
catalogs for a specified file name and attach the copy 
from the first catalog it is found in. 

acquire file 

file name, fn : name 
local file name, Ifn : name 
search_catalogs, sc : list of file 
status : var of status 

file name | fn : This is the file to search for. 

local file name | Ifn : This is the name to use when 
attaching the file. 

search_catalog | sc : These are the catalogs to look 
in. The catalogs are searched in the order 
specified. 


status : see NOS/VE error handling. 
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4.2.2 APPEND TO SPECIAL REQUESTS (APPTSR) 


The purpose of this procedure is to provide a mechanism 
for user and integration procedures to add information to 
a product's SPECIAL REQUESTS. This is a subroutine of 
MAKE_S PECIAL_REQUE STS, CHANGE_MODIFICATION_HEADER, 

CLEAR_INTERLOCK_REQUESTS and others. 

append_to_special_requests 
append file, af : file 
requestor, r : string 
output, o : file 
development base, db : file 
product name, pn : name 
status : var of status 

append file | af : This is the file of information to be 
added to the SPECIAL_REQUESTS file. 

requestor | r : This is the person or procedure appending 
the information. It is used for audit-trail 
purposes. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

status : see NOS/VE error handling. 


4.2.3 BACKUP USER CATALOG TO TAPE (BACUCT) 


The purpose of this proc is to backup the current $user 
catalog to a tape. The catalog can then be restored using 
RESTORE_USER_CATALOG_FROM_TAPE. 

NOTE: when doing backups of the user catalog, any file 
attached in write mode is not backed up. 
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backup_user_catalog_to_tape 

vsn, V : string = $job(user) 
status : var of status = $optional 

vsn : The external and internal vsn of the tape to use for 
backup. 

status : See NOS/VE error handling. 


4.2.4 BIND OS LIBRARY (BINOL) 


This procedure is a subroutine for the procedure 
LINK OPERATING SYSTEM. The purpose of this procedure is 
to bind the specified operating system library. NOTE : If 
the same file is specified for the unbound library and 
bound library, the bound library is written over the 
unbound library. 


This procedure is driven by a set of decks which exist on 
the OS source library. There is one deck for each object 
library to be bound. These decks contain the actual 
binding directives for the library in question. The 
format of these decks is RAF$BD <library name> where 
<library name> is one of the component libraries of the OS 
minus the "OSES" prefix (eg. JOB_TEMPLATE_2DD, 
SYSTEM_CORE_113, etc.). 

bind os library 

binding directives, bd : file 
unbound library, ul : file 
bound library, bl : file 
status : var of status 

binding directives | bd : This file contains the library 
specific directives for the os library. Required 
parameter. 

unbound library | This is the file that contains the data 
to be linked. Required parameter. 


bound library | This is the file to recieve the results of 
the link. Required parameter. 
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status : see NOS/VE error handling. 


4.2.5 BUILD ANAD COMMAND LIBRARY (BUIACL) 


The purpose of this procedure is to create a command 
library to aid in examining the dumps associated with a 
particular build level. This procedure will create a 
library of scl procedures to process most of the type 
definitions in the system. 

build anad command library 

anad_command_library, acl : file = acl 
working catalog, wc : file = $optional 
working build level, wbl : name = $optional 
status : var of status = $optional 


anad command library | acl : This is the file to put the 
dump analysis library on. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


4.2.6 BUILD BUILTIN LIBRARY (BUIBL) 


The purpose of this procedure is to build 
osf$builtin library. NOTE : This procedure expects to 
have access to externally defined working environment 
variables. 

build builtin library 

preserved file path, pfp : file 
cybil_run time library, crtl : file 
delete modules, dm : file 
status : var of status 
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preserved file path [ pfp : This is the destination of the 
library 

after it is built. Required parameter. 

cybil run time library | crtl : This is the cybil 
CYF$RUN_t™e_LIBRARY to use to satisfy external 

references. Required parameter. 

delete module | delete modules | dm : specifies a file 
containing one or more lines each of which is a 
module deletion directive. The format of these 
directives should be : 

delete_module module status= ignore_status 

The status must be specified as shown. If not specified 
in this manner the procedure will abort. 

Omission causes no modules to be deleted. 

status : see NOS/VE error handling. 


4.2.7 BUILD SYSTEM IDENTIFIERS 


The purpose of this request is to initialize the variables 
BUILD ID and VERSION ID. These variables are used by the 
linking process to initialize the system level 
identifiers. 

The IDENITIFIER FILE is needed for future linking done at 
the site and contains code to create and initialize the 
BUILD_ID and VERSION_ID at that time. 

The formats for the BUILD ID and VERSION ID are as 
follows: 

BUILD ID = 'NOS/VE '//operating system level//' '// .. 
product_set_level//' ' 

VERSION_ID = 'NOS/VE '//release_level//' '// .. 
psr summary level//' ' 

Where the OPERATING_SYSTEM_LEVEL is a 5 character field 
containing alphanumeric. The PRODUCT SET LEVEL is a 6 
character field containing alphanumeric. Both of these 
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are left justified blank filled. The RELEASE_LEVEL is a 5 
character field containing a numeric followed by a '.' 
then a numeric followed by another '.' and finally another 
numeric. The PSR SUMMARY LEVEL is a 6 character field 
containing an 'L' followed by a 3 character numeric and 
finally an optional 2 character alpha (bcu level). This 
is left justified blank filled as well. An example of 
each is given below : 

1234567890123456789012 

BUILD_ID = NOS/VE 12615 4RD 
VERSION_ID = NOS/VE 1.1.3 L644AA 

build_system identifiers 

build id, bi : var of string 
version id, vi : var of string 
identifier file, if : file 
operating system level, osl : string 1..5 
product_set_level, psl : string 1..6 
release level, rl : string 1..5 
psr summary level, pi : string 1..6 
status : var of status 

build id I bi : The NOS/VE internal level id codes. 

version id | vi : The NOS/VE external level id codes. 

identifier file | if : A file released as part of the 
system code, which identifies the system. 

operating system level | osl : The numeric part of an OS 
build level. 

product set level | psl : The numeric part of a sunnyvale 
build level. 

release level | rl : The release management id level. 

psr summary level | pi : The customer services BCU/PSR id 
level. 


status : see NOS/VE error handling. 
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4.2.8 BUILD TASKS LIBRARY (BUITL) 


The purpose of this procedure is to build osf$tasks. 

NOTE: This procedure expects to have access to externally 

defined working environment variables. 

build tasks library 

preserved file path, pfp : file 
cybil run time library, crtl : file 
delete modules, dm : file 
status : var of status 

preserved file path | pfp : This is the destination of the 
library after it is built. Required parameter. 

cybil run time library | crtl : This is the cybil 
CYF$RUN_t™e_LIBRARY to use to satisfy external 
references. Required parameter. 

delete module | delete modules | dm : specifies a file 
containing one or more lines each of which is a 
module deletion directive. The format of these 
directives should be : 

delete_module module status= ignore_status 

The status must be specified as shown. If not specified 
in this manner the procedure will abort. 

Omission causes no modules to be deleted. 


status : see NOS/VE error handling. 


4.2.9 CHANGE OBJECT LIBRARY (CHAOL) 


This procedure will combine an object text file with an 
existing object library or will create a new object 
library from the object text. If an old object library is 
specified but no value is given for a new object library, 
the old object library will be overwritten. 
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change object_library 

new object text, not : file 
old_object_library, ool : file 
new object library, nol : file 
status : var of status 

new_object_text | not : This is the data to be added to to 
the library. Required parameter. 

old object library | ool : This is the library to have 
data added to it. 

Default if omitted : no old library. 

new object library | nol : This is the file to write the 
combined library to. 

status : see NOS/VE error handling. 


4.2.10 CHANGE TEST GROUPS 


This proc changes the groupname for all decks with the 

specified groupname 

change_test_groups 

old group, og : name = $optional 
new_group, ng : name = $optional 
delete group, dg : list of name = $optional 
status : var of status = $optional 

old group | og : This is the group whose attributes are to 
be changed. 

new group | ng : This is new group attribute to be added 
to all decks. 

delete group | dg : This is an existing group attribute to 
be removed from all decks. 


status : See NOS/VE error handling. 
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This procedure checks that all decks, modifications, 
features, etc. exist and creates a selection criteria 
file that includes all of them and a verify states file 
which includes a unique list of feature names that is 
passed back to TRANSMIT SOURCE (the main subroutine of 
TRATI and TRATFC) for further checking, 
check params for trat 
base : file 

decks : list of name or key all 
modifications : list of name 
features : list of name 
selection criteria : file 
verify states : file 
status : var of status 

base : This is the scu source library upon which all decks 
modifications and features, to be checked; reside. 

decks : This is a list of decks whose associated 
modifications and features are to be verified. All 
features associated with state 0 modifications 
associated with these decks are put onto the 
verify states file (if it is specified). 

modifications : This is a list of modifications whose 
assocated features are to be verified. All features 
assocated with modifications on this list are added 
to the verify states file (if it is specified). 

features : This is a list of features to be verified. All 
entries in this list are added to the verify states 
file (if it is specified). 

selection criteria : This is a scu selection criteria 
file. It will have include deck (or modification, or 
feature) entries added for each of the items listed 
on the parameters above. 

verify states : This is a file of unique feature names 
which is passed back to transmit source for further 
checking. 


status : see NOS/VE error handling. 
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4.2.12 CHECK SPECIFIED DEPENDENCIES (CHESD) 


The purpose of this procedure is to check the specified 
dependencies. First the feature list is searched for each 
dependencies. If some aren't found in the feature list, 
then the state of the code is checked. State 1 code is 
assumed missing. State 3 is assumed built if the feature 
cannot be found the expanded build decks for the 
base build level. 

check specified dependencies 

feature list, fl : file = $required 
base build level, bbl : name = $required 
output, o : file = $response 
product name, pn : name = os 
status : var of status = $optional 

feature list : fl : A file of features (WEF$FEATURE LIST 
format) which are assumed to be dependencies of a 
specified feature. 

base build level | bbl : This is the standard level 
against which any state three dependencies will be 
compared. 

output I o : This is the file to which any problems are 
written. 

product name | pn : specifies the system or product to be 
used. 

status : See NOS/VE error handling. 


4.2.13 CLEANUP FILE CYCLES (CLEANUP FILE CYCLE CLEFC) 


The purpose of this procedure is to provide a consistant 
mechanism for procedures to use for cleaning up whenever 
they write cycles of files. 

cleanup_file_cycles 
file, f : file 

retention lenth, rl, r : integer 
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4.2.13 CLEANUP FILE CYCLES (CLEANUP FILE CYCLE CLEFC) 


retention count, rc : integer 
set_expiration_date, sed : boolean 
status : var of status 

file I f : This is the file to be cleaned up. It should 
be the n-lst cycle of the file if at all possible. 
If it is not possible to point to the n-lst cycle; 
then set expiration date should be set false to 
prevent accidental loss of all cycles of the file. 

retention_length | rl : This is the length of time to set 
the expiration date of the file to. 

Default if omitted : one day. 

retention count | rc : This is the maximum number of OLD 
cycles to keep around (excluding the highest). Any 
cycles beyond this count will be deleted; regardless 
of their expiration date - lowest cycle number 
first. 

Default if omitted : four old cycles. 

set expiration date | sed : This parameter inhibits the 
setting of an expiration date on the cycle of the 
file specified on the file parameter. 

Default if omitted : set the expiration date. 

status : see NOS/VE error handling. 


4.2.14 COMBINE SCU LIBRARIES (COMSL) 


The purpose of this procedure is to merge scu libraries 
onto a base library and then rewrite the base library. 

combine scu libraries 
base, b : file 
subset, s : file 
enforce interloks, ei : boolean 
status : var of status 

base I b : This is the file to have the subset library 
added to it. 
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subset I s : This is the library to add. 

enforce interlocks | ei : This controls whether interlocks 
are checked or not. 

status : see NOS/VE error handling. 


4.2.15 COMPRESS JOB LOG (COMJL) 


This is a subroutine of BUILD EXEC. It's purpose is to 
extract the most useful information ina job log created by 
a MAKE_BUILD JOBS-generated batch job. 

compress_j ob_log 

job_log, jl : file 
output, o : file 
status : var of status 

job log I jl : This is the file which contains the dayfile 
of a compile job produced by MAKE BUILD JOBS. 

output I o : This is the file to write the results to. 

status : see NOS/VE error handling. 


4.2.16 COMPRESS LINK MAP (COMLM) 


This procedure will look for link map in working, feature 
catalog and build level. It then output all compressed 
link map on one file and produces binary map if specified 


compress link_map 

output, o : file = compressed link map 
display_options, do : list of key compressed, c, 
alphabetical_order, ao, 
compress production map, .. 
cpm : boolean = true 

compress recovery map, crm: boolean = false 
compress job template, cjt: boolean = true 
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production binary map, pbm: file = 

production binary map 

recovery binary map, rbm : file = recovery binary map 

development base, db : file = .intve 

product name, pn : name = os 

build_level, bl : name = Soptional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = $optional 

output I o : This is the file to put the compressed 
linkmap upon. 

display options | do : This selects the method of 
compression. 

compress production map | cpm : This selects whither the 
linkmap for the production system is compressed. 

compress recovery map | crm : This selects whither the 
linkmap for the recovery system is compressed. 

NOTE: This is an obsolete parameter. 

compress_job_template | cjt : This selects that the job 
template map be compressed along with the system core 
map. 

production binary map | pbm : This is the file to receive 
the binary linkmap (used by QUERY DEBUG TABLE among 
others). 

recovery binary map | rbm : This is the file to receive 
the binary linkmap (used by QUERY DEBUG_TABLE among 
others) for the recovery system. 

NQTE: This is an obsolete parameter. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

product name | pn : specifies the system or product to be 
used. 


build level | bl : specifies the system or product build 
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level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build_level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 


status : See NOS/VE error handling. 


4.2.17 COPY LABELLED TAPES (COPLT COPY LABELLED TAPE) 


This procedure copies labelled tapes on the 180 side by 
first requesting both the source tape and the target tape, 
then doing a COPY FILE on them. If a list is specified 
for the TARGET VSN, the procedure will continue to copying 
the remaining tapes if one of the tapes does not copy 
correctly. It will specify the external vsn of the bad 
tape and it will also return bad status. 

copy_labelled_tapes 

source vsn, svsn : name 1..6 = $required 

target vsn, tvsn : list of name 1..6 = $required 

recorded vsn, rvsn : name 1..6 = $required 

type, t : key mt9$800, mt9$1600, mt9$6250 = mt9$1600 

status : var of status = $optional 

source vsn | sv : This is the external vsn for the 
original copy of the tape. 

target_vsn | tv : This is the external vsn for the new 
copy of the tape. 

recorded vsn | rv : This is the internal vsn on both 
copies of the tape. 


type I t : Tape density. 



User Documentation for Development on NOS/VE 
Working Draft - Revision 7 
4.0 SUBROUTINES 

4.2.17 COPY LABELLED TAPES (COPLT COPY LABELLED TAPE) 


4-33 

08/25/91 


status : See NOS/VE error handling. 


4.2.18 COPY MULTI RECORD TAPES (COPMRT COPY MULTI RECORD TAPE) 


The purpose of this procedure is to copy NOS/VE deadstart 

tapes. 

copy_multi_record_tapes 

source vsn, svsn : name 1..6 = $required 
target vsn, tvsn : list of name 1..6 = $required 
type, t : key of, mt9$800, mt9$1600, mt9$6250 = 
mt9$6250 

status : var of status = Soptional 

source vsn | sv : This is the external vsn for the 
original copy of the tape. 

target vsn | tv : This is the external vsn for the new 
copy of the tape. 

type I t : Tape density. 

status : See NOS/VE error handling. 


4.2.19 COUNT FEATURE LINES (COUFL) 


This is a subroutine used by MAKE BUILD REQUESTS to return 
statistics on the feature being requested; one deck at a 
time. 

count feature lines 
deck, d : name 
feature, f : name 

lines before feature, Ibf : var of integer 
lines deleted. Id : var of integer 
lines added, la : var of integer 
processor, p : var of string 
status : var of status 


deck I d : This is the deck to return statistics on. 
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feature | f : This is the feature to return statistics 
on. 

lines before feature | Ibf : This returns the size of the 
deck (active lines) before the feature is added. 

lines deleted | Id : This is the number of INTEGRATED 
lines of code which are deleted. 

lines added | la : This the number of new lines 
introduced. 

processor | p : This is the value in the deck's processor 
field 

status : see NOS/VE error handling. 


4.2.20 CREATE EMPTY FILE (CREEP) 


This is a subroutine which creates a file with no 
contents. 

create_empty_file 

file, f : file 
status : var of status 

file I f : The file to create. 

status : see NOS/VE error handling. 


4.2.21 CREATE INTEGRATION DESCRIPTORS (CREID) 


This procedure will create the program descriptors 
normally found in the tools library. The tying file will 
be used to determine where the program descriptors will 
get files, normally in the build catalog specified by 
wev$build level. The target build level parameter can be 
used to override the tying file value and point to 
whatever target build level is specified. 
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create integration descriptors 
command library, cl : file 
target build level, tbl : name 

termination error level, tel : key warning, w, error, 

e, fatal, f = warning 

create load map, elm : boolean 

cybil level, cybl : name 

build level, bl : name 

working catalog, wc : file or key none 
working build level, wbl : name 
feature catalog, fc : file or key none 
feature build level, fbl : name 
status : var of status 

command library | cl : This is the file to receive the 
newly created program descriptors. 

Default if omitted : .INTVE.OS.<build level>. 

target build level | tbl : This is the build level to use 
for all os path names. 

build level | bl : specifies the OS build level to be 
used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 

status : see NOS/VE error handling. 


4.2.22 CREATE MULTIPLE SUBCATALOGS (CREMS) 


This is a subroutine which is used to create subcatalogs 
to any desired depth, given a path name. 
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create_multiple_subcatalogs 
catalog, c : file 
status : var of status 

catalog | c : This is the catalog to create, 
status : see NOS/VE error handling. 


4.2.23 CREATE OPEN SHOP DI OBJECT (CREOSDO) 


The purpose of this request is to create the 

OPEN_SHOP_DI_OBJECT by combining all the found CDCNET TIPS 
with the DI OBJECT for a given version level. If 

OPEN SHOP DI OBJECT already exists the proc returns. If 
OPEN_SHOP_DI_OBJECT does not exist and there are no CDCNET 
TIPS found, the DI OBJECT is copied to create 

OPEN_SHOP_DI_OBJECT anyway. 

create_open_shop_di_obj ect 

build level, bl : name = $optional 
feature catalog, fc : file or key none = none 
feature build level, fbl : name = object 
working catalog, wc : file or key none = none 
working build level, wbl : name = object 
status : var of status = $optional 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build level | wbl : specifies the working build 
level to be used. 


status : See NOS/VE error handling. 
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4.2.24 CREATE SUBTEST LISTS 


This is a subroutine to CREATE_TESTNAMES_LISTS, which 
creates the list of subtest names. For more information 
on subtests; consult testing documentation. 

create_subtest_lists 

status : var of status 

status : see NOS/VE error handling. 


4.2.25 EXAMINE LINK MAPS (EXALM) 


This procedure will look in the working, feature and 
build_level catalogs for the specified link maps. 'OS' 
will use SYSTEM_CORE_LINK_MAP and JOB_TEMPLATE_LINK_MAP. 
'El' will use C170_EI_LINK_MAP. And, 'BOOT' will use the 
BOOT LINK MAP. It calls wem$search link map to find 
errors in the link maps and collects the errors found, if 
any, on the file $local.linker_errors. If the value of 
the DISPLAY OPTIONS parameter is ERRORS, the link maps 
will be deleted and the performance summary file will not 
be generated. If PERFORMANCE SUMMARY is specified then 
the summary file will be generated as long as there 
weren't linker errors. The link maps will be deleted in 
either case. If FULL is specified, the summary files will 
be kept as long as there aren't linker errors and the link 
maps are kept either way. Note, the performance summary 
is only generated for system core link maps and 
job template link_maps. 

examine link maps 

link map type, Imt: key 
boot, ei, os 
keyend = os 

display_options, do: key 
(errors, e), 

(full, f), 

(performance summary, ps) 
keyend = performance summary 

product name, pn: name = wev$product name, os 
build level, bl: name = wev$build level, $optional 
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feature_catalog, fc: any of 
key 
none 
keyend 
file 

anyend = wev$feature catalog, none 

feature build level, fbl: name 

wev$feature_build_level, object 

working catalog, wc: file = $user 

working build level, wbl: name 

wev$working build level, object 

status) 


link map type | Imt : This selects whether to check the 
map for the system boot, the system maps or the map 
for the environmental interface. 

display options | do : This parameter is used to control 
the link map and the link map summary files. If 
ERRORS is specified the link maps are deleted and the 
summaries are not generated. If PERFORMANCE SUMMARY 
is specified, and if there are no errors the link 
maps are deleted but the summary files are left 
alone. If FULL is specified, and if there are no 
errors the summary files are kept. If there are 
errors the summary files are deleted. The link maps 
are saved in either case. Note, the performance 
summary file is only generated for 

system core link maps and job template link maps. 

product name ! pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build_level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. This parameter defaults to $user. 

working build level | wbl : specifies the working build 
level to be used. 



User Documentation for Development on NOS/VE 


4-39 


Working Draft - Revision 7 
4.0 SUBROUTINES 

4.2.25 EXAMINE LINK MAPS (EXALM) 


08/25/91 


status : See NOS/VE error handling. 


4.2.26 DUMP CATALOG (DUMP CATALOGS DUMC) 


This is a utility procedure used to archive catalogs onto 
backup tapes. The procedure will submit a batch job to 
perform the actual backup. 

dump_catalog 

catalog, catalogs, c : list of file 
vsn : list of string 1..6 

job_class, jc : key batch, local, maintenance 
list, 1 : file = $list 

password, pw : name = $name($job(user)//'x') 
status : var of status 

catalog | catalogs | c : This is the list of catalogs to 
dump onto the tape(s). 

vsn : This is name of the tape to do the backup to. 

job class I jc : This is the job class in which to submit 
the backup job. 

list I 1 : This is the file to write the output from the 
backup onto. 

password | pw : This is the user's password (needed for 
the batch job). 

status : see NOS/VE error handling. 


4.2.27 EXPAND BUILD DECKS (EXPAND BUILD DECK EXPBD) 


This is a subroutine used by any procedure which needs to 
access the build decks maintained by integration. This 
procedure will expand the deck onto a local file, which 
can then be used as input to an scu criteria file 
parameter. 
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expand build decks 

expanded build decks, expanded build deck, ebd : file 
product name, pn : name 
build level, bl : name 

working catalog, wc : file or key none 
feature catalog, fc : file or key none 
status : var of status 

expanded build decks | expanded build deck | ebd : This is 
the file to receive the expanded build level deck. 

Default if omitted is the product name concatenated 
to the end of the build level; with the result 
truncated at 31 characters. 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


4.2.28 EXTRACT SOURCE MODULES (EXTRACT SOURCE MODULE EXTSM) 


This is a subroutine used by EXTRACT SOURCE. It is the 
procedure which does the actual extract. 

decks, deck, d : array of string or key all 

interlock, i : boolean 

selection criteria, sc : file 

list, 1 : file = $local.log list 

development base, db : file 

product name, pn : name 

build level, bl : name or key none 

feature catalog, fc : file or key none 

working catalog, wc : file or key none 

status : var of status 
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decks I deck | d : This is the list of decks to extract. 

interlock | i : This controls whether the interlocks are 
set during the extract process or not. 

selection_criteria | sc : This is an scu selection 
criteria file which is used to select additional 
features when extracting without interlocks. 

list I 1 : This is the file which receives the log data 
from the extract; and which EXTRACT SOURCE will 
append to the logging file in the appropriate product 
catalog. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name 1 pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


4.2.29 EXTRACT SUBSET SOURCE LIBRARY (EXTSSL) 


This is a subroutine whose purpose is to extract a 
selected subset from each of the integration, feature and 
working libraries and then combine the pieces to form a 
new library. 

extract_subset_source_library 

selection criteria, sc : file 
result, r : file 
development base, db : file 
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product name, pn : name 
build level, bl : name 

feature catalog, fc : file or key none 
working catalog, wc : file or key none 
status : var of status 

selection criteria | sc : This is the file which selects 
the contents of the new library. 

result I r : This is the file to receive the new library. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


4.2.30 EXTRACT VE COMMON DECKS (EXTVCD) 


The purpose of this procedure is to extract a canned list 
of OS common deck needed by the AV product; at a selected 
build level. 

extract ve common decks 

result, r : file = $local.ve common decks 
development base, db : file 
product name, pn : name 
build level, bl : name or key none 
status : var of status 


result I r : This is the file to receive the extracted 
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subset source library. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

build_level | bl : specifies the system or product build 
level to be used. 

status : see NOS/VE error handling. 


4.2.31 FORMAT HEADER DECK (FORHD) 


'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

DESCRIPTION NEEDED ««- 

'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

format header deck 

status : var of status = $optional 

status : See NOS/VE error handling. 


4.2.32 GENERATE BINARIES (GENERATE BINARY GENB) 


The purpose of this procedure is to insulate 
COMPILE SOURCE from any fatal compiler errors or compiler 
non-existance. 

generate binaries 

processor, p : string 

input, i : file 

binary, b : file = binary 

list, 1 : file = $list 

list options, lo : list of name 

status : var of status 


processor | p : The compiler name. 
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4.2.32 GENERATE_BINARIES (GENERATE_BINARY GENB) 

input I i : The file of source to be compiled. 

binary | b : The location to place the result of the 
compile. 

list I 1 : The file to receive the compile result list. 

list options | lo : This parameter selects which items the 
compiler is to report. 

status : see NOS/VE error handling. 

4.2.33 GENERATE CDCNET PRODUCT TAPE (GENCPT) 


This procedure is used to generate a CDCNET product tape. 

The procedure can pro from either the NOS/VE integration 

catalog or the CDCNET integration catalog. N 

Version catalog should be equal the catalog path up to the 

version catalog. 

generate_cdcnet_product_tape 

version catalog, vc : file = $optional 

installation catalog, ic : file = 

$user.installation_catalog 

save installation catalog, .. 

sic : boolean = false 

external_vsn, evsn : string 1..6 = $optional 
type, t : key mt9$800, mt9$1600, mt9$6250 = mt9$6250 
build level, bl : name = $optional 
status : var of status = $optional 

version catalog | vc : This is the catalog which contains 
the CDCNET build. 

installation catalog | ic : This is the NOS/VE 

installation catalog to create. 

save installation catalog | sic : This controls whither 
the installation catalog created will be saved or 
deleted. 

external vsn | ev : This is the external vsn for the new 
copy of the tape. 
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type I t : Tape density. 

build level | bl : specifies the system or product build 
level to be used. 

status : See NOS/VE error handling. 


4.2.34 GENERATE DELETE MODULE COMMANDS (GENDMC) 


This procedure creates the commands to add the group 

attribute 'DELETED DECKS' to decks deleted in a build. 

generate delete module commands 

build requests, br : file = $required 
command file, cf : file = $output 
status : var of status = $optional 

build requests | br : This is the build requests for all 
of the new features added to a build. 

command file | cf : This is the file of commands to add 
the 'DELETED_DECKS' attributes. This file is appened 
to the product's SPECIAL_REQUESTS file. 

status : See NOS/VE error handling. 


4.2.35 GENERATE FEATURE CRITERIA (GENFC) 


The purpose of this procedure is to generate 

include modified deck criteria directives for the features 

on the include feature list file. The format of the 

include feature list file is: 

include feature feature name 1 

include feature feature name 2 

etc. 

generate feature criteria 

include feature list, ifl : file = $required 
criteria commands, cc : file = $required 
include copying decks, icd: boolean = true 
status : var of status = $optional 
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include feature list | ifl : This is the list of new 
features. 

criteria commands I cc : This is the file of 

'INCLUDE_MODIFIED_DECKS' commands. 

include copying decks | icd : This controls whither the 
ICD parameter of the INCLUDE_MODIFIED_DECKS is true 
or false. 

status : See NOS/VE error handling. 


4.2.36 GENERATE HELP MODULE (GENHM) 


This is a language processor subroutine for 

COMPILE SOURCE. It's purpose is to feed help screens into 

an object library. 

generate help module 

input, i : file = $required 
binary, b : file = $local.lgo 
error, e : file = $errors 
list, 1 : file = $null 
list_options, list_option, .. 
lo : list of name = $optional 
status : var of status = $optional 

input I i : This file contains the source text. 

binary | b : This is the file where the result object 
library is to end up. 

list I 1 : This is the file to put the listing onto. If 
compile source's save listing parameter is not none, 
the listing is massaged prior to output. 

list options | lo : This parameter exists only to provide 
compile source with a uniform interface. It is 
ignored by this procedure. 


status : See NOS/VE error handling. 
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The purpose of this procedure is to regenerate the library 
wev$development base.COMMAND LIBRARY and the files 
wev$development base.BACKUP a wev$development base.RESTORE 

generate integration procedures 

development base, db : file = .intve 
status : var of status = $optional 


development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

status : See NOS/VE error handling. 


4.2.38 GET 170 JOB RESULTS (GETIJR) 


This procedure is a subroutine whose purpose is to 
retrieve and interpret a file created by a 170 job which 
contains the creation command for a 180 status variable 
that will contain the status of the 170 job. The 
procedure will also retrieve the 170 job's dayfile. 

get_17 0_j ob_resuits 

results file 170, rf7 : name 1..7 

results file 180, rf8 : file = $local.nos results 
dayfile 180, dl : file = $local.dayfile 170 
status : var of status 

results file 170 | rf7 : This is the name of the 170 file 

containing the status variable. 

results file 180 | rf8 : This is the 180 file to retrieve 
the 170 file to. 


dayfile 180 | dl : This is the file to retrieve the job's 

dayfile to. 


Default if omitted : DAYFILE 170. 
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4.2.39 GET BUILD LEVEL (GETBL) 


The purpose of this procedure is to retrieve a default 
value for a product's build level. This default value is 
stored in the version field of the product 
source library. 

get build_level 

source library, si : file 
build_level, bl : string 
status : var of status 

source library | si : The library to reference for the 
version. 

build level | bl : specifies the system or product build 
level to be returned. 

status : see NOS/VE error handling. 


4.2.40 GET NEXT INTVE PRODUCT (GETNIP) 


The purpose of this procedure is to return, one-by-one, 
the names of the product level catalogs in a master 
catalog. A subcatalog is considered a product only if it 
contains both a source_library and latest changes 
accessable to the caller in read mode. 

get next intve product 

development base, db : file 
development base contents, dbc : string 
product value : var of string 
status : var of status 

development base | db : specifies the catalog in which all 
products and build levels reside. 


Default if omitted : .INTVE 
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development base contents | dbc : The name of a file 
containing the DISPLAY CATALOG of the 

development base level catalog. This file must not 
be rewound before calls to GETNIP. 

product value | pv : The variable to receive the next 
product name. 

status : see NOS/VE error handling. 


4.2.41 GET TAPE VSN (GETTV) 


This procedure retrieves tape vsns from the tape library 

for tapes reserved with the reserve build tape procedure. 

get_tape_vsn 

group, g : name 

tape, t : key s051cip, s052cip, slcip, s2cip, s3cip, 
s4cip, s5cip, nos_deadstart, ve_deadstart, 

full_product, short_product, test, backup_build_l, 
backup build 2, backup build 3, backup build 4, 
backup build_5, ic backup_l, ic backup 2, nos_base 
volume serial number, vsn : var of string 
status : var of status 

group I g : This is the group classification to assign to 
the tape. Current standard is the build_level. 

tape I t : This is the tape useage classification to 
assign to the tape. 

volume serial_number | vsn : This i the variable to 
receive the assigned tape's vsn. 

status : see NOS/VE error handling. 


4.2.42 INSTALL TESTS (INST) 


This procedure moves files from the wev$development base 
catalog to the TESTVE c then backs up the TESTVE master 
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catalog to tape. The backing up of files is done if the 
tape vsn parameter is specified, and files are moved to 
TESTVE only if their corresponding parameter was 
specified; i.e., if parameter os build leve was specified, 
those test files in the wev$development base.OS subcatalog 
are mo TESTVE prior to the backup to tape. This allows 
the TESTVE catalog to be updated with any particular 
product's test files. This procedure SHOULD NOT BE 
EXECUTED when there is either a load on NOS/VE (prime 
time) or when the TESTVE catalog is being used due to the 
use of tape for backup and the potential impact to users 
of TESTVE files. 

BE AWARE: Parameter TTBL when invoked, creates a high 
cycle of the file .TESTVE.TEST_TOOLS.BOUND_PRODUCT. 
However, the low cycle cannot be deleted by this 
procedure's batch job, since this file lives in RING 7, 
and the batch job i permitted only to delete in RING II. 
Interactively you can reach RING 7 (Using T commands). 
This is most advisable since each invoking of the TTBL 
parameter fill considerably more & more memory disk 
space. Also, in RING 7 you will have to iss a CHAFA 
.TESTVE.TEST_TOOLS.BOUND_PRODUCT RA=(7,13,13) command to 
assist correct WRITE/READ/EXECUTE ring level permits to 
this file. 

install_tests 

os build level, obi : name = $optional 
scu build level, sbl : name = $optional 
cybil build level, cbl : name = $optional 
ocu build level, ocbl : name = $optional 
system_test_build_level, . . 

stbl : name = $optional 
test_tool_build_level, .. 

ttbl : name = $optional 

tape_vsn, tv : string 1..6 = $optional 
development base, db : file = .intve 
status : var of status = $optional 

os build level | obi : The build catalog to get the os 
test set from. 

scu build level | sbl : The build catalog to get the scu 
test set from. 

cybil_build level | cbl : The build catalog to get the 
cybil test set from. 
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ocu build level | ocbl : The build catalog to get the ocu 
test set from. 

system test build level | stbl : The build catalog to get 
the system_tests test set from. 

test tool build level | ttbl : The build catalog to get 
the test_tools test set from. 

tape vsn | tv : The tape to write the tests onto. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

status : See NOS/VE error handling. 


4.2.43 LIST INTERLOCKS (LIST) 


The purpose of this procedure is to list all decks with 
interlocks, and the values of the interlocks. It expects 
to be called from inside of a scu source library. 

list interlocks 

~list_file : file = $OUTPUT 
status : var of status 

list file : This is the file to display to information 
to. 

status : see NOS/VE error handling. 


4.2.44 LIST VALID PROCESSORS (LISVP) 


The purpose of this procedure is to return the list of all 
of the language types accepted as "valid" by 
transmit to integration. 

list valid processors 

status : var of status = $optional 
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status : See NOS/VE error handling. 


4.2.45 MAKE LOG ENTRY (MAKLE) 


The purpose of this procedure is to log extracted and 
transmitted decks. It will append the contents of 
log file to the file LOGGING that is contained under each 
product catalog. 

make log entry 

log file. If : file 
development base, db : file 
product name, pn : name 
status : var of status 

log file I If : This is the file of information to save. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product to be 
used. 

status : see NOS/VE error handling. 


4.2.46 MERGE OBJECT LIBRARIES (MEROL) 


The purpose of this procedure is to merge object libraries 
from the integration, feature and working catalog levels 
to produce a aggregate library. This procedure expects 
that the working envionment variables be declared 
externally. 

merge object libraries 

delete modules, dm : file 
object library, ol : name 
result object library, rol : file 
omit library, oml : name or key none 
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no libraries_merged, nlm : var of boolean 
status : var of status 

delete modules | dm : This is a list of modules to delete 
after all of the libraries have been merged. 

object library | ol : This is the name of the file to 
merge. 

result object library | rol : This is the aggregate 
library. 

omit library | ol : The allows one of the libraries to be 
skipped. 

no_libraries merged | This variable is set true if there 
are no feature or working catalog versions of the 
object library; otherwise it is false. 

status : see NOS/VE error handling. 


4.2.47 MODIFY TEST LIST GROUPS DECK (MODTLGD) 


This proc adds an entry to a table in the deck 
EVI$TEST LIST GROUPS so that a new list will become part 
of the .TESTVE testname lists. These lists are created by 
CREATE_TESTNAMES_LISTS which uses the table to determine: 

(1) the file paths of the lists to be created 

(2) the scu groups that are associated with each list 

(3) the product that the list belongs to The intent of 
this procedure is to add a new list entry to the 
table, or by setting NEW LIST to false, add an entry 
which will cause tests to be appended to the end of an 
existing list in the table. If you wish to to modfiy 
an existing entry you must do it manually. 

In order to use this proc you must first perform the 
following: 

(1) extract deck EVI$TEST_LIST_GROUPS from the PROGS 
product library 

with interlocks using EXTS 

(2) assign a modification using ASSM 

(3) enter your working environment (**this proc can 
not be called while 
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outside the working environment**) 

After these steps are completed you can call this proc to 

modify the deck. 

modify test list groups deck 

modification, m : name = $optional 

product_name, pn : key os, ps_quicklooks, ocu, scu, 
system_tests, av = 

test list file path, tlfp : string = $optional 

groups, group, g : list 1..3 of name = $optional 

new list, nl : boolean = TRUE 

help, h : file = $null 

status : var of status = $optional 

modification | m : The modification which was created 
using ASSM. 

product name | pn : Product that the list will belong to. 

test list file path | tlfp : The partial file path of the 
list that that will be created. 

groups I group | g : Any test decks having these will be 
associated with the list. 

new list | nl : If FALSE then the file given for 

TEST LIST FILE PATH refers to one that is already in 
the table. The intent is that tests with the 

specified groups will be appended to that list. This 
allows tests with different groupnames to all be 
associated with one list. 

help I h : This will produce some online help 
information. 

status : See NOS/VE error handling. 


4.2.48 OMIT LIBRARY (OMIL) 


The purpose of this procedure is to omit the specified 
library references from the library that is being 
created. NOTE : Must be in the create object_library 
utility to call this procedure, all load modules in the 
current library will have the specified library reference 
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omitted. 
omit library 

library to omit, Ito : name = cyf$run time library 
status : var of status 

library to omit | Ito : This is the library reference to 
remove. 

status : see NOS/VE error handling. 


4.2.49 PARSE CATALOG (PARC) 


This procedure will separate the files and subcatalogs 
that exist within the specified catalog. A list of the 
subcatalogs are written to the file specified for the 
catalog list parameter and a list of the files are written 
to the file specified for the file list parameter. The 
number of catalogs and number of files parameters return 
the number of elements in the respective lists. 

parse_catalog 

catalog, c : file = $catalog 
catalog_list, cl : file = $output 
file list, fl : file = $output 

number of catalogs, noc : var of integer = $optional 
number of files, nof : var of integer = $optional 
status : var of status = $optional 

catalog | c : The catalog to parse. 

catalog list | cl : The file to receive the list of 
subcatalogs. 

file list I fl : The file to receive the list of files. 

number_of_catalogs | noc : The number of entries in 

CATALOG_LIST. 

number of files | nof : The number of entries in 

fIle~list. 


status : See NOS/VE error handling. 
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The purpose of this procedure is to print a file on the 

laser printer; using 8 1/2 x 11 paper. This procedure 

will generate formatting directives for the file. 

print laser file 

file, f : file 

format, fmt : key of, document, d, listing, 1 : 

listing 

number of sides, nos : integer 1..2 = 2 
pages_per_side, pps : integer 1..2 = 1 
copies, c : integer 1..32 = 1 
shift_left margin, slm : boolean 
status : var of status 

file I f : The file to print. 

format | fmt : This controls whether the file is printed 
with the lines horizontal normal mode (DOCUMENT) or 
turned sideways so that the lines run vertically from 
bottom to top (LISTING). 

number of_sides | nos : This controls single or double 
sided printing. 

pages per side | pps : This controls the number of printed 
pages that are to be put onto each side of each piece 
of paper. 

copes I c : The number of copies to make. 

shift left margin | slm : This shifts the page slightly 
towards the right siade of the page to facilitate 
binding the document. 

status : see NOS/VE error handling. 


4.2.51 PROCESS TEST DECKS (PROTD) 




DESCRIPTION NEEDED «« 
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process_test_decks 

deck list, dl : file = $required 
scu_base, sb : file = $required 
product name, pn : name = os 
catalog, c : string = $required 
status : var of status = $optional 

—» PARAMETER DESCRIPTIONS NEEDED «— 

product name | pn : specifies the system or product to be 
used. 

status : See NOS/VE error handling. 


4.2.52 QUERY DEBUG TABLE (QUEDT) 


This procedure invokes the utility which will produce the 
address, the segment, display the address and other 
attributes for each section in the module. It ca a 
procedure name and output the address, and the module name 
from the system deb 

IF a file is specified for the debug_table parameter this 
proc will use that bin If the keyword SYSTEM is specified, 
it will search the working catalog, feature and 
build level catalog for a file called: system debug table 
If the keyword R is specified, the NOS/VE system 
currently running on the computer is searched fo 

query_debug_table 

debug_table, dt : file or key system, s, 

running system, rs, boot, b 

input, i : file = $input 

output, o : file = $output 

build level, bl : name = $optional 

feature catalog, fc : file or key none = none 

feature build level, fbl : name = object 

working catalog, wc : file or key none = none 

working build level, wbl : name = object 

status : var of status = $optional 

debug_table | dt : This selects the reference source that 
QUEDT will use to look up references. System is the 
one from the working environment settings; 
running system is the one in the currently exicuting 
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system and boot is the boot debug table from the 
working environment. 

input I i : This file to take the queries from. 

output I o : This is the file to write the response data 
to. 

build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 

working build_level | wbl : specifies the working build 
level to be used. 

status : See NOS/VE error handling. 


4.2.53 REPLACE 170 FILE (REP170F) 


The purpose of this procedure is to replace one of the 170 
files NVELIB, NVEBINS, NOSBINS or RH170 to the 170 side 
using REPLACE MULTI RECORD FILE. The file must come from 
the appropriate position in the working environment 
structure. 

replace 170 file 

file name, fn : name = $required 
development base, db : file = .intve 
product name, pn : name = os 
build level, bl : name = $optional 
feature catalog, fc : file or key none = none 
feature build level, fbl : name = object 
working catalog, wc : file or key none = 
working build level, wbl : name = object 
status : var of status = Soptional 


none 
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file name | fn : The file to replace. 

development base | db : specifies the catalog in which all 
products and build levels reside. 

Default if omitted: .INTVE 

product name | pn : specifies the system or product to be 
used. 


build level | bl : specifies the system or product build 
level to be used. 

feature_catalog | fc : specifies the feature catalog to be 
used (if any). 

feature build_level | fbl : specifies the feature build 
level to be used. 

working catalog | wc : specifies the working catalog to be 
used. 


working build level | wbl : specifies the working build 
level to be used. 


status : See NOS/VE error handling. 


4.2.54 RETURN ENVIRONMENT FILE PATH (RETEFP) 


Procedure to search working catalog, feature catalog and 
build level catalog and for environmental files, then 
return the path as a string if found. 

return environment file path 

file name, fn : name = $required 

file type, ft : key cip, compiled, linked, general, 
pp, z80 = gener 

path, p : var of string = $optional 
development base : file = .intve 
product name : name = os 
build level : name 

feature catalog : file or key none = none 
feature build level : name = object 
working catalog : file or key none = 
working build level : name = object 


none 
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status : var of status = $optional 

file name | fn : The file name to search for. 

file_type | ft : The place to search, 
cip : The CIP subcatalog 
compiled : The MAINTENANCE subcatalog, 
linked : The build level subcatalog. 

genereral : Either the build level or MAINTENANCE 

level subcatalog. 

pp : The OSFSPP subcatalog. 

z80 : The OSF$Z80 subcatalog. 

*block,10,h5 

path I p : This is returned path to the appropriate 
catalog containing the file. 

development base | db : specifies the catalog in 
which all products and build levels reside. 

Default if omitted : .INTVE 

product name | pn : specifies the system or product 
to be used. 

build level | bl : specifies the system or product 
build level to be used. 

feature_catalog | fc : specifies the feature catalog 
to be used (if any). 

feature build level | fbl : specifies the feature 

build level to be used. 

working catalog | wc : specifies the working catalog 
to be used. 

working build level | wbl : specifies the working 

build level to be used. 


status : See NOS/VE error handling. 
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The purpose of this procedure is to count the number of 

lines on a text file. 

return file length 

file, f : file = $required 

length, 1 : var of integer = $required 

status : var of status = $optional 

file : The file whose length is to be returned. 

length : The variable to which the line count is 
returned. 

status : See NOS/VE error handling. 


4.2.56 RUN LINK JOB (RUNLJ) 


The purpose of this procedure is to execute a NOS/170 

batch job from the 180 side. 

run link job 

file, f : file 
wait, w : boolean 
recursive call, rc : boolean 
status : var of status 

file I f : This contains the NOS batch job. 

wait I w : This controls whether the 180 and 170 jobs are 
to be run syncronously or asynchronously. 

recursive call | rc : This parameter is not for external 
use. 


status : see NOS/VE error handling. 
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4.2.57 SAVE BUILD JOB STATUS (SAVBJS) 


This is a procedure used in jobs created by 

MAKE BUILD_JOBS. It reports the job's status to a file 

that is interpreted by BUILD EXEC. 

save_build_j ob_status 

status_file, sf : file 
job name, jn : name 
job_status, js : name 
product name, pn : name 
build level, bl : name 
status : var of status 

status file | sf : This is the file to report to. 

job name | jn : This is the name of the current job. 
(MAKBJ assigns each job a name equal to the object 
library it is compiling to.) 

job_status I js : This is the status value to report. 

product name | pn : specifies the system or product to be 
used. 

build level | bl : specifies the system or product build 
level to be used. 

status : see NOS/VE error handling. 


4.2.58 SELECT DECKS BY MODIFICATION 


This is a subroutine of RE EXTRACT SOURCE. It's purpose 
is to determine which decks are affected by a list of 
modifications. 

select decks by modification 

modifications, m : array of string 
modification index : integer 
selected_decks, sd : file 
selected deck count : var of integer 
status : var of status 
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modifications | m : This is the list of modifications for 
which we want modified decks. 

modification index | mi : This is the starting index in 
the list of modifications. 

selected decks | sd : This is the file to append the newly 
selected decks to. 

selected deck count | sdc : This is the number of decks 
added to the selected_decks file. 

status : see NOS/VE error handling. 


4.2.59 SELECT MODS BY FEATURE 


This procedure insures that all modifications in a list 

have a given feature name. 

select_mods_by_feature 

modifications : array of string 
features : array of string 
selected modifications : file 

selected modification count : var of integer 
status : var of status 

modifications | m : This is the list of modifications for 
which we want to check states. 

feature | f : This is the feature under which all selected 
modifications must exist. 

selected modifications | sm : This is the file to append 
the newly selected modificaitons to. 

selected modification count | smc : This is the number of 
modifications added to the selected modifications 
f ile. 


status : see NOS/VE error handling. 
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4.2.60 SELECT MODS BY STATE (SELMBS) 


This procedure insures that all modifications in a list 

have a given state. 

select_mods_by_state 

modifications, m : array of string 

state : integer 0..1 

selected_modifications, sm : file 

selected modification count : var of integer 

status : var of status 

modifications | m : This is the list of modifications for 
which we want to check states. 

state I s : This is the state in which all selected 
modifications must exist. 

selected modifications | sm : This is the file to append 
the newly selected modificaitons to. 

selected modification count | smc : This is the number of 
modifications added to the selected modifications 
f ile. 

status : see NOS/VE error handling. 


4.2.61 SELECT UNIQUE NAMES (SELUN) 


This is a subroutine of RE EXTRACT SOURCE. It's purpose 
is to add to a file of names any names not already there. 

select unique names 

new names : array of string 
new names ub : integer 
selected names : file 

selected names count : var of integer 
status : var of status 

new names : This is the list of candidate names to add to 
the file. for which we want modified decks. 
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new names_ub : This is the upper bound of the new names 
array. 

selected names : This is the file to append the newly 
selected names to. 

selected names count : This is the number of names added 
to the selected names file. 

status : see NOS/VE error handling. 


4.2.62 STANDARDIZE LIBRARIES (STAL) 


The purpose of this procedure is to massage the object 
libraries in a given product to put the modules in the 
right order and delete unsed modules. For os libraries 
external modules will be added and the references to the 
cybil run time library wil be omitted. 

standardize libraries 

library and format, laf : list 1..32, 1..2 of name = 
$optional 

delete modules, dm : file = $null 
product name, pn : name = $optional 
build level, bl : name = $optional 
status : var of status = $optional 

library and format | laf : The list of files to 
standardize. 

delete modules | dm : A list of modules to remove. 

product name | pn : specifies the system or product to be 
used. 


build_level | bl : specifies the system or product build 
level to be used. 


status : See NOS/VE error handling. 
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This procedure standardize list of names by: 

1) convert each line to a name and translate 

2) eliminating leading blanks 

3) sorting 

4) eliminating duplicate entries 

standardize name list 

input, i : file = $required 
output, o : file = $optional 

translate, t : key upper_to_lower, utl, 

lower_to_upper, Itu = uppe 

status : var of status = $optional 

input I i : This file contains names to standardize. 

output I o : This is the file to receive the standardized 
list. 

Default if omitted : input 

translate | t : This controls the character conversion, 
status : See NOS/VE error handling. 


4.2.64 TRANSMIT SOURCE (TRAS) 


This is the procedure which performs the transmit 
operations done by both TRANSMIT_TO_INTEGRATION and 
TRANSMIT_TO_FEATURE_CATALOG. 

transmit source 

from base, fb : string 
to_base, tb : string 
selection criteria : file 
last_to_base : string 
verify states : file 

change_states, change_state, cs : boolean 
status : var of status 


from base | fb : This is the library to transmit from. 
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to base | tb : This is the library to transmit to. 

selection criteria : This is the information to transmit. 

last_to_base : This is used to pass the product_name 
source library to TRAS from TRATI (to base= 
LATEST~CHANGES). ~ 

verify states : This will cause the procedure to check 
that states match between the two libraries (on the 
mods transmitted). 

change states | change state | cs : This will cause the 
procedure to change all transmitted state 0 mods to 
state 1. 

status : see NOS/VE error handling. 


4.2.65 UNBUNDLE LISTINGS (UNBUNDLE LISTING UNBL) 


This is a subroutine of COMPILE SOURCE. It will take a 
compiler's listings, seperate them by module, create a 
deck on a listing library for each module's listings and 
place group attributes on the deck giving the compiler's 
name and the severity of errors on the module listing. 

unbundle listings 

list file. If : file 
processor, p : name 

list library, 11 : name : listing library 

save listings, si : key all, good, fatal, warning, 

none = all 

working catalog, wc : file or key none 
status : var of status 


list file I If : This is the file containing the compiler 
listings. 

processor | p : The compiler name. 

list library | 11 : This is the scu source library to 
place the listings upon. 


save listings | si : This selects the severity of the 
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listings to save. (Note : saving warning listings 
saves fatals as well.) 

working catalog | wc : specifies the working catalog to be 
used. 

status : see NOS/VE error handling. 


4.2.66 VALIDATE DECK (VALD) 


The purpose of this procedure is to insure that all 
required fields in the deck header contain valid values. 

validate_deck 

deck, d : name = $optional 
output, o : file = $output 
status : var of status = $optional 

deck I d : The deck to validate. 

output I o : The file to write errors onto. 


status : See NOS/VE error handling. 
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BACKWARD CHAINING - A method of building characteristic of 
secondary builds. The *copys in each build deck 
point to it's predecessor. Build decks are also 
characterized by the use of include feature 
commands pulling in unintegrated code. 

BIG 3 - A set of regression tests which include the OS 
quicklooks, product set quicklooks and 
performance quicklooks. 

CBL - Commercial Benchmark Library. A set of benchmark 
tests designed to simulate business 

enviornments. This set is characterized by an 
emphasis on COBOL and by relatively small 
amounts of arithmatic computation. 

DCT - The Development Coordinating Team. A group 
responsible for planning the contents of each 
build and each release. 

FORWARD CHAINING - A method of building characterists of 
primary builds. The *copys in each build deck 
pint to it's successor. Build decks are also 
characterized by the user of exclude feature 
commands excluding integrated code. 

IBL - Interactive Benchmark Library. A set of benchmark 
tests designed to test interactive response 
times. 

MASTER MACHINE - The machine upon which integration does 
it's work and upon which the master portion of 
the update jobs are executed. 

OS QUICKLOOKS - A set of regression tests that are 
designed to quickly spot major flaws in a new 
level of OS. 

PERFORMANCE QUICKLOOKS - A set of benchmark tests that are 
designed to quickly spot major degradations in 
response to a new level of the system. 



User Documentation for Development on NOS/VE 
Working Draft - Revision 7 
Al.O GLOSSARY OF TERMS 


Al-2 

08/25/91 


PRIMARY BUILDS - System builds done by integration which 
are part of the system release path. 

PRODUCT SET QUICKLOOKS - A set of regression tests that 
are designed to quickly spot major flaws in a 
new level of the Sunnyvale product set or in the 
product set's interface with the system. 

SBL - Scientific Benchmark Library. A set of benchmark 
tests designed to simulate engineering 

environments. This set is characterized by an 
emphasis on FORTRAN and by relatively large 
amounts of arithmatic computation. 

SECONDARY BUILDS - Systems builds done by integration 
which are not part of the system release path. 
These builds are, typically, done to aid a 
particular group. These builds are usually 
discarded once the need for them is ended, 
instead of being used as the basis for the next 
build level. 

SLAVE MACHINE - Any machine used by the NOS/VE department 
closed shop that is not a master machine. 

SN MID CORRELATION - A file used by the update jobs to 
determine which machine is the master machine 
and which are slave machines. It also contains 
information about the method of communicating 
between the machines. 

SPECIAL REQUESTS - A file which exists in each product 
catalog on the master machine. This file forms 
a repository for all library change directives 
that will be executed on the particular product 
during the next execution of the update job. 

TYING - A file which exists in each OS build level 
subcatalog. The purpose of this file is to link 
(or tie) the OS build level with the correct 
level of each of the other available products. 
It also will tie the OS level to the 170 
catalogs containing the NOS and NOS/BE levels 
and to the set of tapes which are used to test 
the system. 

UPDATE JOBS - A set of procedures designed to be run as 
batch jobs during off shift time. The purpose 
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of the updat jobs is to maintain the source 
libraries for all products across all machines. 
The update jobs also provide a mechanism for 
introducing and distributing the changes 
integration makes to the libraries during builds 
and other operations. 

WEF$FEATURE LIST - A file which exists in a user's feature 
or working catalogs. It is used by many working 
enviornment procedures to override the 
build level value a user has selected, adding 
the code that the user has developed back into 
the included set. 
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One of the obvious requirements of this environment is the 
ability to hold more than one version of the 
operating system, products, etc. 

Each build level (version) of the operating system or 
product will have a name of the form 

BUILD xxxxx, where "x" designates the level. 
Since a name in NOS/VE cannot contain characters 
such as "/" and such characters should be 

"mapped to" the character when composing a 

build level name. Build levels are generally 
restricted to eleven characters or less because 
of the need to add descriptive information to 
the decks which reside on the source libraries, 
and which control the build contents. It is 
possible to use names longer than eleven 
characters, but they may be truncated by 
procedures which need to utilize the descriptive 
information. 

All source (or text) data for all build levels will be 
stored in the same SCU library. SCU 

modifications and features will be used to 
represent the incremental changes that transform 
one version of the SCU library into the next. 

In addition to source data, there may be certain tools 
(compiler, linker, etc.) which are unique to 
one or more build levels of a product. If such 
is the case, a tools command library will exist 
for each such build level of the product. When 
specified by the tools library build level 
parameter of the SET_WORKING_ENVIRONMENT 
command, the tools command library for the 
build level will be added to the user's command 
list. 
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A2.1 BUILD SUBCATALOGS 


There will be a subcatalog for each operating system 
build. The name of this subcatalog will be that 
of the build level. This subcatalog will 
contain the object libraries that together form 
the operating system and the files that result 
from linking the operating system. 

These files are used both by integration and by developers 
who are working on additions or changes and need 
to put together a system for checkout. When 
they link a system their changes are combined 
with these full libraries prior to the actual 
linking taking place. 

In addition to the files for the system itself, there is a 
subcatalog for the feature test list. The files 
in this catalog are subsequently moved to the 
TESTVE catalog. 

System tests are considered to be a "product" and as such 
are maintained in their own "product 

subcatalog". Likewise, test tools are 
considered to be a "product" and are maintained 
in their own "product subcatalog". 


A2.2 SCU REPRESENTATION OF A BUILD LEVEL 


Corresponding to each build level on a SCU library there 
will be a deck named according to the build 
level. 

The contents of each such deck will specify what was added 
to the library in the subsequent build. Thus, 
when build "n" is added to the library, an empty 
deck called BUILD n is created. Then when build 
"n+1" is added, deck BUILD n is updated to list 
those things that were included in the new build 
level preceded by a "*COPY,BUILD n+1". 

The "subsequent build content" is represented by SCU 
selection criteria commands such as 

"EXCLUDE FEATURE,f" where "f" identifies a 
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"feature" introduced in the next build. 

In order to permit easy backward and forward tracing of 
build levels, the deck descriptions of the 
"build decks" will be used as well as the 
library_description. The deck description for 
build "n" will have the form : 

Predecessor Build = BUILD n-1 Successor Build = BU 

in which the build level names will be left justified, 
space filled in a 31 character field. This permits a 
fixed method of access to the predecessor and successor 
build level names. If there is no predecessor or 
successor the corresponding field of the deck description 
should have the value "NONE". 

The "version" in the header of the SCU library will 
have the form : 


BUILD_x 

providing a pointer to the most recent build. 


A2.2.1 REPRESENTATION OF A DELETED DECK 


Because more than one build level is maintained on the 
source library, it is not feasible to actually delete 
decks from the library that become obsolete at a certain 
build, since such decks are still needed by previous 
builds. 

To delete a deck, the developer should generate a 
modification which deletes all lines from the deck, 
leaving 0 active lines on the deck. This modification 
should be transmitted with the appropriate increment. The 
group DELETED DECKS is added to the deck when the feature 
deleting the deck is incorporated into a system by 
integration. The DELETED DECKS group is used for 
informational purposes. When the source library is 
resequenced, if the modification is at state 4, and the 
group attributes equal DELETED DECK, the deck will be 
deleted from the source library. 
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A2.2.2 REPRESENTATION OF A NEW DECK 


When create source creates a new deck, it has the 
"NEW DECKS" group assigned to it. This prevents a new 
deck from being included in a system until it is added to 
a build. 

Once the deck has been added to a build level, it is 
deleted from the group NEW DECKS. 

To prevent a deck added at a certain build level from 
becoming part of all preceding builds, an EXCLUDE DECK 
directive is added to the appropriate "build deck" in a 
manner analogous to that described for deleting a deck in 
the preceding section. 


A2.3 PRODUCT SUBCATALOGS 


Each product will have a subcatalog in the main 
integration catalog. The structure of these subcatalogs 
will, to as great an extent as possible, parallel the 
structure of the operating system subcatalog. 
Specifically this means that the subcatalog will contain a 
source library and a subcatalog for individual builds of 
the product. 

The source library will contain, besides the source 
code for the product itself, the tests for the product and 
procedures to build and maintain the product and its 
tests. 

The product build subcatalogs will parallel the 
structure of the product subcatalogs located in the 
$SYSTEM catalog with the addition of a "tests" subcatalog 
similar in structure and content to the feature tests 
subcatalog for the operating system. 

All non-source (or non-text) data for an individual 
build level will be stored in a subcatalog named according 
to the build level. 
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The use to be made of SCU groups for the operating 
system source library is described in a section below. 
Similar conventions will be followed for each product 
source library as appropriate. 

SCU "groups" will be used on the system source library 
for a number of different purposes. The different types 
of groups are identified by the conventions used to name 
them. Except for the "processor" and "generic" groups 
(described above), the format of all group names is : 

xxy$aaaaaa 

where "xx" is the product identifier associated with the 
group (usually OS), "aaaaaa" is a descriptive name for the 
particular group, and "y" is one of the following : 

S Specifies a "Source" group, i.e. a subdivision 

of the source library into component 

libraries. The groups of this type that have 
been identified are : 

oss$program interface 
oss$source 

oss$real_state_source 

oss$feature_tests 

oss$process_commands 

F Specifies a "destination File" group (i.e. a 

file onto which a deck is to be placed after 
processing). The groups of this type that have 
been identified are : 

osf$j ob_template_rrr 
osf$system_core rrr 
osf$monitor 

osf$obj ect_code_utilities 
osf$tasks 
osf$utilities 
osf$commands 
osf$operator commands 
osf$non standard commands 



User Documentation for Development on NOS/VE 
Working Draft - Revision 7 
Bl.O USE OF "GROUPS" 


Bl-2 

08/25/91 


G Specifies a "Group", i.e. a collection of 

decks that somebody has decided it would be 
useful to be able to refer to en masse (e.g. 
clg$command list management). Examples of 

groups which have been established are : 

LLG$OBJECT_CODE_DEFINITIONS 

PMG$ANALYZE_PROGRAM_DYNAMICS 

IFG$INTERACTIVE 

Most group names will follow the conventions described 
for the operating system source library. However, there 
are two classes of groups for which this is inappropriate 
: "processor" groups and "generic" groups. 

A "processor" group will be given the same name as the 
corresponding processor, e.g. the group name for decks to 
be compiled by CYBIL will be "CYBIL". Other processor 
group names are : 

assemble 

fortran 

cobol 

pp_compass 

cp_compass 

cybil_cc 

program descriptions 

scl_procedures 

ccl_procedures 

Note that some of these must obviously be processed on 
the Nos side of the machine. 

A "generic" group is used in those cases where knowing 
the processor for a deck is insufficient for some 
purpose. The generic groups that have been identified are 


scu_selection_criteria 
deleted_decks 
build_decks 
new decks 

Some of these generic groups overlap to some extent 
with the processor groups. 
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Bl.l USE OF "STATES" 


SOU states will be used to indicate the degree to which 
a modification has been tested. 

State 0 - 'Under Development' 

Code with state 0 modifications resides in the 
feature and working source libraries. State 0 
is used on an integration source library to 
designate a modification that has been 
rejected. 

State 1 - 'Testable' 

Code and test modifications will be transmitted 
to the system source library at state 1. State 
1 modifications have been proven 'testable', 
i.e. a system with state 1 code modifications 
in it is able to deadstart and the tests with 
state 1 modifications for this code execute. 
This code is ready to be tested on the 
developing system. 

State 2 - 'Integrated' 

Code with state 2 modifications has been 
formally integrated into the base system, i.e. 
the base for the developing system, and may be 
included in the set of binary modules that goes 
into the release candidate system, depending on 
the release plan. 

State 3 - 'Release Candidate' 

Code with state 3 modifications has passed a set 
of criteria (e.g. stability, performance, 
documentation criteria) specified in the test 
direction and is being tested by system 
evaluation. 

State 4 - 'Released' 

Code with state 4 modifications has been 

formally released. 
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There will be no state 0 modifications on the system 
source library with the possible exception of those that 
have achieved a higher state and then been rejected for 
some reason. Having no state 0, i.e. experimental code, 
on the system source library also reduces contention 
difficulties. 
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The procedure to convert a NOS library to 180 SCU 
format is fairly simple. Integration maintains files that 
contain lists of the NOS deck names for NOSVEPL, OSLPI, 
and DSPIPL and their corresponding 31 character NOSVE 
names. SCU provides a utility to convert the library and 
substitute the long (31 character) names for the short 
(NOS) names so that calls to other decks remain 
compatible. 

Example : 

getf oldlib dc=b60 

convert madify to scu opl=oldlib .. 

r=$user.new library cs=ascii612 
*(this assumes you are converting a madify libr 
the same files can be used for update librar 
scu b=$user.new library r=$user.long names libr 
delete file connection $ERRORS output 
* the following command will generate errors fo 
decks not found on your library - the above 
command avoids seeing all the warnings, 
change deck names .. 
modification=<assigned modification> .. 
nl=<your name change list> 
crefc $ERRORS output 
end true 

create file permissions $user.long names librar 
group=user am=(all cycle control) sm=none ai=' 

This last statement gives the owner of the file 
permission to extract with interlocks from the library and 
change the state of a modification within the library. 



User Documentation for Development on NOS/VE 

Working Draft - Revision 7 

C2.0 CONVERTING A BINARY TO NOSVE FORMAT 

C2.0 CONVERTING A BINARY TO NOSVE FORMAT 


C2-1 

08/25/91 


To convert an existing binary file to a format usable 
on NOS/VE, the user need only utilize 

Convert_Obj ect_File. 

Example : 

conof to=new bin from=oldbin 
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C3.0 CONVERTING A TEXT FILE TO NOS/VE FORMAT 


Conversion is not needed for text files; they can 
simply be "gotten" and used. 

Example : 

getf to=text from=nostext 
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Following are some examples of some of the processes a 
developer may typically go through to get work done. 


Dl.l INITIAL PREPARATION 


1) Edit or create a user prolog 

2) Add to it a Set Command List of the command library 
(.INTVE.COMMAND_LIBRARY)7 

3) Add to it a Set Working Environment specifying the 
desired parameters. Should specify product name, 
build level, author and working catalog as a 
minimum. 

4) Add to it the Modification Index and 

Modification Initials variables needed to generate 
modification names. (Note - the capital letters are 
necessary for the modification index - be sure to 
use this format.) 

Example : 

edif $user.prolog 

insert 

set command list add=.intve.command library 

set working environment author='C.A.Sheats' 
bl=build 1 11 18 wc=.cas 

create_variable WEVSMODIFICATION_INDEX 
kind=integer scope=job value=l 

create variable wev$modification initials 
kind=string scope=job value='cas ' 

(these create variable lines should be one line - 
not continued via '..'. It was necessary to show 
the lines this way for the benefit of Textform). 
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end 

detach_file $user.prolog 

The following examples assume that the above 
Set Working Environment command is in effect. 


D1.2 CREATING A NEW DECK 


1 Get a modification name (via assign modification) to 
use in the creation of the desired deck. Use 
existing modification name associated with feature 
if have one. 

2 Execute Create_Source to create the deck on the 
working (and/or feature) library. 

3 Call Edit_Source to add text. 

Example : 

assign modification f=source maintenance .. 
md='Original source for new deck' 

create source d=new deck m=cas 27 e=true .. 
dg=osf$commands p='scl' sg=oss$process commands 

edit source m=cas_27 d=new deck 

If there are no decks on the source library, 
assign modification will not display the modification (due 
to a bug in SCU). To find out the modification assigned 
to you, do a display_modification_list of the 
source library. 


D1.3 MODIFYING AN EXISTING DECK 


1 If the deck is not on the working library, execute 
Extract Source 

2 Get a modification name via Assign_Modifications if 
one does not exist for feature working on. 

3 Call Edit Source to make changes 
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Example : 

extract_source d=old_deck 

assign modification f=NV0Z999 .. 
md='Problems in handling output.' 

edit source m=cas 28 d=old deck 


D1.4 COMPILING A DECK 

1 Execute Compile Source 
Example 1 : 

compile source d=dmm$logger p='cybil d=nt' .. 

ol=osf$system core 113 l=listing 

If processor (P) and object library (OL) not specif 
it is figured out by the procedure as in example 2. 

Example 2 : 

compile source dmm$logger l=listing 


D1.5 USING ENTER WORKING ENVIRONMENT 


The Enter Working Environment command enables the user 
to save time and avoid creating unnecessary cycles of the 
working library. 

Example : 

enter working environment 
edit source cas 29 tmm$dispatcher 
compile source tmm$dispatcher l=listing 
edit source cas 29 tmm$dispatcher 
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corns tmm$dispatcher 

etc. 

exit working environment 
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This describes what to do in the case of interlock 
conflicts between users on separate machines. Interlock 
conflicts occur when someone on SN002 and someone on SN109 
extract the same deck on the same day. When this happens, 
the update procedures will detect this and the copy of the 
deck from the machine with the lowest priority is 
rejected. A deck which is rejected ends up on a file 
called .INTVE.product.XMIT_REJECTIONS. 
SDUP <date> <time>. There may be more than one deck upon 
this file depending on the number of rejected decks. 
There may also be more than one file depending on the 
number of slave machines each of whose name differs 
slightly in the date-and-time stamp. 

Whenever integration deects an interlock conflict, it 
is the job of the person responsible for the update jobs 
to resolve the problem. This resolution ranges from 
ignoring the rejected mod to running re extract source on 
it or even to the point of asking the originator to 
recreate it if there are serious conflicts. 
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The procedure of transmitting code to the source 
library "long" ("long" generally means more than one week) 
before it is ready to be built into a system causes severe 
problems for people who need to modify the same deck. 
They would like to modify the deck without any conflicting 
code, but are forced to deal with it because of the way 
SCU operates. This requires building and testing with the 
conflicting feature - which may or may not be possible. 

To avoid these problems, some guidelines are presented 
here. They are not meant to apply to every case, and they 
do require some cooperation between the parties involved. 

1. If a feature being developed will take a "long" 
time, then the decks being modified should be 
extracted without interlocks, and the modifications 
made should not be transmitted to the source library 
(see #3 below). 

2. If a conflict arises where one person is ready to 
transmit code and get it built, but cannot do this 
because of another person's code being present in 
the source library, then, after discussion with the 
owner of the conflicting code, the conflicting code 
may be deleted. Some arrangement should be made to 
save the deleted modset(s) for future use. 

3. The procedure re_extract_source can be used to 
upgrade decks from one build to another. If 
conflicts arise during this process, they must be 
dealt with by hand. It is the feature developer's 
job to upgrade his mods from system to system while 
under development. 

4. When a feature is ready to be transmitted, all decks 
should be extracted with interlocks and the 
accumulated modsets applied (see #3). Conflicts 
should be dealt with as detailed in #2. Once the 
feature is transmitted and a build request has been 
made, no conflict with this code is possible - its 
place in the system is established with the build 
request. Any conflicts after this point must adapt 
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